[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#546823: __thread usage in libcap-ng0 broken on armel

ARM porters: can you shed any light on this?

If I compile libcap-ng0 on armel, then run "make check", the segfault described
in the bug appears:

> make[3]: Entering directory `/home/smcv/bugsquash/libcap-ng-0.6.1/src/test'
> Doing basic bit tests...
> /bin/bash: line 5: 25105 Segmentation fault      ${dir}$tst

On further investigation it appears that whenever &m.something is passed to
memset, I get the segfault. In unmodified source, I get:

> ./libtool --mode=execute gdb ./src/test/lib_test
> GNU gdb (GDB)
> ...
> (gdb) run
> Starting program: /home/smcv/bugsquash/libcap-ng-0.6.1/src/test/.libs/lt-lib_test 
> Doing basic bit tests...
> Program received signal SIGSEGV, Segmentation fault.
> 0x40027630 in init () at cap-ng.c:139
> 139		memset(&m.hdr, 0, sizeof(m.hdr));
> (gdb) thread apply all bt full
> Thread 1 (process 31033):
> #0  0x40027630 in init () at cap-ng.c:139
> No locals.
> #1  0x40027ad4 in capng_clear (set=CAPNG_SELECT_BOTH) at cap-ng.c:159
> No locals.
> #2  0x0000893c in main () at lib_test.c:37
>         rc = <value optimized out>
>         i = <value optimized out>
>         last = <value optimized out>
>         text = <value optimized out>
>         saved = <value optimized out>

If I patch out the calls to memset(&m.hdr, ...) and memset(&m.data, ...)
in init(), replacing them with a single call to memset(&m, 0, sizeof(m)),
then the segfault is delayed until a later call to memset(&m.data, ...).

This ld warning seen during the build seems likely to be related:

> gcc -shared  .libs/cap-ng.o .libs/lookup_table.o   -Wl,-z -Wl,relro -Wl,-z -Wl,defs -Wl,-soname -Wl,libcap-ng.so.0 -o .libs/libcap-ng.so.0.0.0
> /usr/bin/ld: .libs/cap-ng.o(.text+0x810): R_ARM_GOTOFF32 used with TLS symbol m
> /usr/bin/ld: .libs/cap-ng.o(.text+0xc1c): R_ARM_GOTOFF32 used with TLS symbol m

Any ideas?

Attachment: signature.asc
Description: Digital signature

Reply to: