[PATCH v2 2/3] c: Update TLS model after processing a TLS variable

[Joseph Myers]

On Fri, 12 Sep 2025, H.J. Lu wrote:

> On Fri, Sep 12, 2025 at 7:50 AM Joseph Myers <josmyers@redhat.com> wrote:
> 
> > This breaks building glibc with linker errors for some configurations in
> > build-many-glibcs.py (loongarch64-linux-gnuf64 loongarch64-linux-gnusf
> > m68k-linux-gnu-coldfire m68k-linux-gnu-coldfire-soft or1k-linux-gnu).
> >
> > Representative linker errors are as follows.  Of course assertion failures
> > indicate a linker bug as well, but if there really are mixtures of TLS and
> > non-TLS references to the same symbol as suggested by the or1k-linux-gnu
> 
> 
> How does mixing TLS and non-TLS references of the same symbol work?
> X86 linker issues an error if it happens.  It sounds like a glibc bug.

I think the or1k-linux-gnu linker error messages are wrong, since I can't 
find any actual non-TLS references in the object files despite what the 
linker claims.  So I now suspect linker bugs handling LE TLS on the three 
architectures indicated, which were exposed by this GCC mainline change 
affecting the TLS models used.

I've CC:ed the binutils maintainers for those affected targets that are 
maintained (loongarch, or1k).  See 
https://gcc.gnu.org/pipermail/gcc-patches/2025-September/695255.html for 
the specific errors building glibc with GCC and binutils mainline for each 
target.  I've also CC:ed the binutils and libc-alpha lists.  Note that 
m68k binutils has had no maintainer listed since 2008.  Maybe it's time to 
remove support for at least the ColdFire sub-target in glibc if not the 
entire m68k port, ColdFire in particular has other breakage from some 
long-unresolved GCC bug or bugs that frequently comes and goes as a result 
of other changes in GCC.

-- 
Joseph S. Myers
josmyers@redhat.com