[Buildroot] [autobuild.buildroot.net] Daily results for 2022-09-22

[Stafford Horne]

On Mon, Sep 26, 2022 at 11:12:18AM +0000, Stafford Horne wrote:
> On Mon, Sep 26, 2022 at 11:51:13AM +0200, yann.morin at orange.com wrote:
> > Stafford, Waldemar, All,
> > 
> > On 2022-09-26 09:05 +0200, MORIN Yann INNOV/IT-S spake thusly:
> > > On 2022-09-23 16:29 +0000, Stafford Horne spake thusly:
> > > > On Fri, Sep 23, 2022 at 05:23:11PM +0200, Waldemar Brodkorb wrote:
> > > > > > On 2022-09-23 14:13 +0200, MORIN Yann INNOV/IT-S spake thusly:
> > > > > > > On 2022-09-23 05:30 +0000, Thomas Petazzoni via buildroot spake thusly:
> > > > > > > >     or1k     |           gpsd-3.24            | NOK | http://autobuild.buildroot.net/results/7adc125e843b21b559f1e8813059d65af58feb8d |     
> > > > > > > This is an or1k, shared-only, uClibc-ng, LT (not NPTL) so no TLS, build.
> > > > > > >     ..../or1k-buildroot-linux-uclibc-gcc -o gpsd-3.24/gpsctl .... -lusb-1.0 -lm -lrt -lnsl
> > > > > > >     ..../ld: ..../sysroot/usr/lib/libusb-1.0.so: undefined reference to `__tls_get_addr'
> > > 
> > > So, I made some progress in looking at this.
> > [--SNIP--]
> > > So, this hints at a compiler error...
> > 
> > I did a quick fix to libusb to workaround the issue (see attached
> > patch), but this issue is more widespread. For example, libndp fails
> > to build for the same reason:
> > 
> >       CCLD     ndptool
> >     ..../or1k-buildroot-linux-uclibc/bin/ld: ../libndp/.libs/libndp.so: undefined reference to `__tls_get_addr'
> > 
> > So, we can't chase all libraries that will want to use some TLS
> > objects, espeically as the issue may well occur in another package.
> > 
> > I looked at the build options for libusb, and there is absolutely
> > nothing weird going on (see attached log).
> > 
> > The more I look at it, the more it smells like a gcc issue. Thoughts?
> > 
> > In the end, I wonder how we can solve this in Buildroot... Just disable
> > LT for or1k?
> 
> That may be a temporary option.  I didn't get any time to look at this during
> the weekend, but this investigation from you helps a lot.  The --disable-tls may
> be related to the issue.  The compiler may need to do something special to
> disable generation of tls symbols when building with --disable-tls and OpenRISC is
> not doing that.  I am guessing we are always generating the tls code sequences
> and not obeying the --disable-tls flag when we should be.
> 
> I am looking at gcc though right now and I cannot see anything suspicious.  I'll
> keep looking.
> 

OK, it seems this is the fix.  The --enable/disable-tls flag seems to only
control a HAVE_AS_TLS macro in the gcc build.  OpenRISC was missing the below
ifdef.  Adding it seems to fix the build for me.

Thanks Yann for the investigation that pointed right to the issue.

If you all can confirm this, I will post a gcc patch shortly and get it
upstream.

-Stafford

--

diff --git a/gcc/config/or1k/or1k.cc b/gcc/config/or1k/or1k.cc
index da2f59062ba..0ce7b234417 100644
--- a/gcc/config/or1k/or1k.cc
+++ b/gcc/config/or1k/or1k.cc
@@ -2206,8 +2206,10 @@ or1k_output_mi_thunk (FILE *file, tree thunk_fndecl,
 #undef  TARGET_LEGITIMATE_ADDRESS_P
 #define TARGET_LEGITIMATE_ADDRESS_P or1k_legitimate_address_p
 
+#ifdef HAVE_AS_TLS
 #undef  TARGET_HAVE_TLS
 #define TARGET_HAVE_TLS true
+#endif
 
 #undef  TARGET_HAVE_SPECULATION_SAFE_VALUE
 #define TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed