This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: initialization of sdata on ppc & c++ code


Kumar Gala <kumar.gala@freescale.com> wrote on 02/24/2005 09:23:28 AM:

> We have run into an issue recently in that the sdata pointer (r13) on 
> ppc is not initialization in time for use in some early c++ code.
> 

r13 is loaded by start.S before the call to __libc_start_main. 

> Here is a back trace from GDB showing the failure:
> 
> #0  0x10009cbc in strlen ()
> #1  0x0fd0e72c in getenv () from /lib/libc.so.6
> #2  0x0ff4e708 in 
> _GLOBAL__I_.._.._.._.._.._gcc_3.4.3_libstdc___v3_src_allocator_inst.cc_9 

> D2164D3_EA394990 () at mt_allocator.h:163
> #3  0x0ffb8ecc in __do_global_ctors_aux () from /root/libstdc++.so.6
> #4  0x0ff3b79c in _init () from /root/libstdc++.so.6
> #5  0x3000bb54 in _dl_init () from /lib/ld.so.1
> #6  0x3000f138 in realloc () from /lib/ld.so.1
> 
But library _init code is called by the loader before transfering control 
to _start. I assume that you want the .sdata of your application and not 
ld.so? 

> We have a custom strlen that uses sdata that is crashing because r13 is 
> not setup correctly.  I'm wondering if this is expected behavior 
> because _setup has yet to be called and that it is not feasible for 
> 'standard' libc functions to depend on sdata or is this an issue that 
> can be resolved (some how moving sdata init earlier).  The very early 
> initialization is a bit of black magic to me :)
> 
> We are using gcc-3.4.3 and glibc-2.3.1.

This is the way it works and has not have not changed. As I read the ABI, 
current behavior is correct. "The value of _SDA_BASE is an executable is 
normally loaded into r13 at process initialization time, r13 thereafter 
remains unchanged." 

Your problem is that library initialization precedes process 
initialization (__libc_start_main). But this is normal: "After the dynamic 
linker has built the process image and performed relocations, each shared 
object gets the opportunity to execute some initialization code. All 
shared objects initialization happens before the executable file gains 
control."

Steven J. Munroe
Linux on Power Toolchain Architect
IBM Corporation, Linux Technology Center


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]