OSDev.org

getenv_r.c


Can someone explain where the initialization of p_environ takes place?

When relocated to form a static binary?
or when _init() traverses _init_array?

It shouldn't be in .bss as it is not zero

I'll be in .data, with a relocation entry ensuring that it has the correct value after linking.

assuming I have my sections correct....

would objcopy'ing to binary format negate the initialization?

Code runs... but p_environ is 0 and not address &environ.

This is driving me nuts - I have checked init/fini, etc...

I did test of



a isn't even being set... so it must be sections...

thanks!

I believe that static variables can only be initialized using constant literals. I find it good practice to always explicitly assign an initial value to a static variable within a function.

Don't assume, check.



It should not, however check your .data section in the .o file with objdump and then compare with results of objcopy-ing it.

True for C. Not true for C++.


It stands out more. But static is sufficiently visible alone (first thing on a line).

Thank you all for the input... it was the sections.. but it was also a typo...

an extra "f" in my ld script in DATA_SEGMENT_ALIGN()

was chucking these variables out into my kernel heap....

the kernel is loaded in binary format (no elf loader) so the code ran... right up to the point
that the kernel heap started using that area for something else....

interestingly I memset kernel heap regions to 0 when I allocate them... So..... the p_environ was showing 0 as well... had I used a canary value this might have been fixed alot sooner...



The code snippet is from newlib's getenv_r.c file...

I though what you thought as well... that's why I opened the thread.

Thank you again everyone. my eyes are tired from reading hex...