Various Topics on C++

..a.. ..bram..i..

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

.... ..rris..

"Anand Subramanian" <anand@cs.uwaterloo.ca> wrote in message
news:cb2alm$667$1@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

....

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:

Cl***A ObjectA;

Cl***B 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