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

[Simon McVittie-7]

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) 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

[Pierre Chifflier-5]

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

--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[martinwguy]

On 9/28/09, Pierre Chifflier <pchifflier@...> wrote:
> On Sat, Sep 26, 2009 at 04:28:36PM +0100, Simon McVittie wrote:
>  > ARM porters: can you shed any light on this?

>  As I have no armel platform here (and no knowledge specific to the
>  architecture), some help would be appreciated.

There is a big fast armel box here you can use over ssh. Just suggest
a username by private email. It is also set to give Bus Error on
misaligned data accesses instead of the default behaviour of returning
garbage values, which often helps catch mysterious bugs.

   M


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Simon McVittie-7]

It appears that the segfaults in libcap-ng0 described in my earlier bug report,
caused by (or at least related to) use of R_ARM_GOTOFF32 relocations with
TLS symbols, can be avoided by compiling libcap-ng without optimization.
I attach an interdiff; for your convenience, it also includes fixes for the
two minor bugs I just reported.

I suspect that the R_ARM_GOTOFF32 thing may be a bug in gcc or some other
toolchain component (perhaps gcc is applying an inappropriate optimization?),
but I've run out of toolchain knowledge. Is there a toolchain or ARM guru who
can pick this up?

Thanks,
    Simon

diff -u libcap-ng-0.6.2/debian/changelog libcap-ng-0.6.2/debian/changelog
--- libcap-ng-0.6.2/debian/changelog
+++ libcap-ng-0.6.2/debian/changelog
@@ -1,3 +1,15 @@
+libcap-ng (0.6.2-1.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Don't optimize on armel, to work around overly aggressive optimization (?)
+    on __thread variable. Closes: #546823
+  * Fix NAME sections of man pages so whatis can understand them (Lintian
+    warning).
+  * Install .pc file so pkg-config can be used to find libcap-ng (dh_install
+    warning).
+
+ -- Simon McVittie <smcv@...>  Thu, 22 Oct 2009 22:22:28 +0000
+
 libcap-ng (0.6.2-1) unstable; urgency=low
 
   * New upstream release
diff -u libcap-ng-0.6.2/debian/rules libcap-ng-0.6.2/debian/rules
--- libcap-ng-0.6.2/debian/rules
+++ libcap-ng-0.6.2/debian/rules
@@ -23,7 +23,10 @@
 PYDEF=$(shell pyversions -d)
 PYVERS=$(shell pyversions -r)
 
-
+# armel compiler doesn't seem to do too well at __thread if optimizing
+ifeq ($(DEB_BUILD_GNU_TYPE),arm-linux-gnueabi)
+CFLAGS += -O0
+endif
 
 # shared library versions, option 1
 version=2.0.5
diff -u libcap-ng-0.6.2/debian/libcap-ng-dev.install libcap-ng-0.6.2/debian/libcap-ng-dev.install
--- libcap-ng-0.6.2/debian/libcap-ng-dev.install
+++ libcap-ng-0.6.2/debian/libcap-ng-dev.install
@@ -3,4 +3,5 @@
 usr/lib/lib*.so
 usr/lib/*.la
+usr/lib/pkgconfig/*.pc
 usr/share/aclocal/*
 usr/share/man/man3/*
only in patch2:
unchanged:
--- libcap-ng-0.6.2.orig/docs/capng_set_caps_fd.3
+++ libcap-ng-0.6.2/docs/capng_set_caps_fd.3
@@ -1,6 +1,6 @@
 .TH "CAPNG_SET_CAPS_FD" "3" "June 2009" "Red Hat" "Libcap-ng API"
 .SH NAME
-capng_set_caps_fd \-
+capng_set_caps_fd \- write file-based capabilities to extended attributes
 .SH "SYNOPSIS"
 .B #include <cap-ng.h>
 .sp
only in patch2:
unchanged:
--- libcap-ng-0.6.2.orig/docs/capng_get_caps_fd.3
+++ libcap-ng-0.6.2/docs/capng_get_caps_fd.3
@@ -1,6 +1,6 @@
 .TH "CAPNG_GET_CAPS_FD" "3" "June 2009" "Red Hat" "Libcap-ng API"
 .SH NAME
-capng_get_caps_fd \-
+capng_get_caps_fd \- read file-based capabilities from extended attributes
 .SH "SYNOPSIS"
 .B #include <cap-ng.h>
 .sp