I was actually completely incorrect as to the root cause. My initial assumption that the TLS virtual address was being updated correctly when the .rel.dyn was being updated by elf_machine_relative was flawed. The way that I updated that value is only valid when used with an ldso. This is because __libc_setup_tls pulls the virtual address of the TLS out of the auxvals, which i'm not currently updating. I'm trying to figure out if there is a way to either have __libc_setup_tls check to see if there is a TLS entry in the dynamic relocations or make an efficient method of updating the auxval entry prior to __uClibc_main.
I did some digging and it looks like lr is getting modified when calling reloc_static_pie. I'm going to submit a new patch which makes sure any applicable registers are appropriately cleaned up after returning from reloc_static_pie.
Here is a more detailed backtrace.
Program received signal SIGSEGV, Segmentation fault.
_memcpy () at libc/string/arm/_memcpy.S:445
445 libc/string/arm/_memcpy.S: No such file or directory.
(gdb) backtrace
#0 _memcpy () at libc/string/arm/_memcpy.S:445
#1 0x2a027ce4 in __libc_setup_tls (tcbsize=8, tcbalign=16) at
./libpthread/nptl/sysdeps/generic/libc-tls.c:212
#2 0x2a026ac0 in __uClibc_init () at
libc/misc/internals/__uClibc_main.c:284
#3 0x2a026e74 in __uClibc_main (main=0x2a002c68 <main>, argc=1,
argv=0xbef29684, app_init=0x2a0006d0 <_init>, app_fini=0x2a053694
<_fini>, rtld_fini=0x0, stack_end=0xbef29684) at
libc/misc/internals/__uClibc_main.c:423
#4 0x2a0280a4 in reloc_static_pie (load_addr=<error reading variable:
Cannot access memory at address 0xffffff30>) at
libc/misc/internals/reloc_static_pie.c:29
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
_______________________________________________
devel mailing list -- devel@uclibc-ng.org
To unsubscribe send an email to devel-leave@uclibc-ng.org