Global variables in C and C++ problem

[Anand Subramanian]

Hi,
Can someone explain the differences(setup, pre-main()
setup/initialization) between global variables in a C++ and a C program?
The global variables I used are uninitialized.

I have a test.o which declares a global int " int xxx;". Now I link
test.o to a FreeBSD kernel module which then tries to access xxx. If
test.o was compiled from C source the kernel can access the global
variable (which should be of course its own copy in kernel space and not
the test.o linked to the user-space application process). But if the
test.o was generated from C++ source and libstdc++ etc. are linked to
the kernel module then the kernel freezes upon accessing xxx.

Before accessing the integer xxx, I do set the CR3 memory address-space
context for the user process address space. So that the address space
for the user process becomes visible to the kernel(as often happens with
a system call).

My only question is : why can the kernel access the global variable xxx
in a C program but fails in case of a global int in a C++ program? Is it
because of the constructor support for the C++ object file or things
called before C++ main() etc.? Or is there any other reason?

Any help is appreciated.
Thanx,
Anand

[John Harrison]

"Anand Subramanian" <an***@cs.uwaterloo.ca> wrote in message
news:cb**********@rumours.uwaterloo.ca...

Hi,
Can someone explain the differences(setup, pre-main()
setup/initialization) between global variables in a C++ and a C program?
The global variables I used are uninitialized.

I have a test.o which declares a global int " int xxx;". Now I link
test.o to a FreeBSD kernel module which then tries to access xxx. If
test.o was compiled from C source the kernel can access the global
variable (which should be of course its own copy in kernel space and not
the test.o linked to the user-space application process). But if the
test.o was generated from C++ source and libstdc++ etc. are linked to
the kernel module then the kernel freezes upon accessing xxx.

Before accessing the integer xxx, I do set the CR3 memory address-space
context for the user process address space. So that the address space
for the user process becomes visible to the kernel(as often happens with
a system call).

My only question is : why can the kernel access the global variable xxx
in a C program but fails in case of a global int in a C++ program? Is it
because of the constructor support for the C++ object file or things
called before C++ main() etc.? Or is there any other reason?

Any help is appreciated.

I think you want news:comp.unix.programmer . There is too much platform
specific stuff in your question for you to be on topic in this group.

john

[JKop]

Anand Subramanian posted:

Hi,
Can someone explain the differences(setup, pre-main()
setup/initialization) between global variables in a C++ and a C program?
The global variables I used are uninitialized.

I have a test.o which declares a global int " int xxx;". Now I link
test.o to a FreeBSD kernel module which then tries to access xxx. If
test.o was compiled from C source the kernel can access the global
variable (which should be of course its own copy in kernel space and not
the test.o linked to the user-space application process). But if the
test.o was generated from C++ source and libstdc++ etc. are linked to
the kernel module then the kernel freezes upon accessing xxx.

Before accessing the integer xxx, I do set the CR3 memory address-space
context for the user process address space. So that the address space
for the user process becomes visible to the kernel(as often happens with
a system call).

My only question is : why can the kernel access the global variable xxx
in a C program but fails in case of a global int in a C++ program? Is it
because of the constructor support for the C++ object file or things
called before C++ main() etc.? Or is there any other reason?

Any help is appreciated.
Thanx,
Anand

Just a thought, but it might be the following problem:

ClassA ObjectA;

ClassB ObjectB = ObjectA.MakeB();
Global objects/variables are allocated/constructed in no particular order in
a C++ program. If this is your problem, there's a solution in the FAQ.
-JKop