On Sat, Sep 26, 2009 at 04:28:36PM +0100, Simon McVittie wrote:
> ARM porters: can you shed any light on this?
Hi,
As I have no armel platform here (and no knowledge specific to the
architecture), some help would be appreciated.
Regards,
Pierre
>
> 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) 6.8.50.20090628-cvs-debian
> > ...
> > (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?
> Simon