uclibc segfault in ldso

[Joakim Tjernlund]

On Thu, 2008-03-27 at 17:56 +0000, Nigel Kukard wrote:
> > > 
> > > > hmm, should not func address change when loadaddr change?
> > > 
> > > Not sure if its a func address or a string, i just outputted %s  ;)
> > 
> > It is a address, print tpnt->loadaddr, tpnt->dynamic_info[DT_INIT] and dl_elf_func. 
> > dl_elf_func should be tpnt->loadaddr + tpnt->dynamic_info[DT_INIT]
> > 
> > > 
> > > 
> > > -N
> 
> Ok, here is a vanilla uClibc from SVN....  its x86 architecture.
> i386/pentium-mmx .
> 
> 
> $ rpm
> argc=1 argv=0xbfbe8094 envp=0xbfbe809c

[SNIP]
> _dl_malloc:926: mmapping more memory
> _dl_get_ready_to_run:748: Beginning relocation fixups
> _dl_get_ready_to_run:831: calling INIT: /lib/libc.so.0, tpnt->loadaddr =
> 0xb7bfa000, tpnt->dynamic_info[DT_INIT] = 0x54c7f, dl_elf_func =
> 0xb7c4ec7f
> 
> Segmentation fault

This trace looks like it is missing LD_DEBUG=1 rpm or LD_DEBUG=all rpm,
such a trace can get very big so you need to trim it down before
posting. You also need SUPPORT_LD_DEBUG=y in .config

Are you sure that it is the call to 
DL_CALL_FUNC_AT_ADDR (dl_elf_func, tpnt->loadaddr, (void(*)(void)));
that SEGVs? A printout before and after will confirm that.

Also, you said earlier that dl_elf_func was the same for a successful
and a failed run? You need to do the printout I asked for in both cases
to confirm that.

Anyhow, assuming it is the libc's INIT that SEGs, try setting a BP in
libc/misc/internals/__uClibc_main.c, __uClibc_init() and single step to
see what SEGs.

 Jocke