sparcv9 build failure with GCC mainline

sparcv9 build failure with GCC mainline

[Joseph Myers]

Since GCC commit f31a019d1161ec78846473da743aedf49cca8c27 "Emit funcall 
external declarations only if actually used.", the glibc testsuite has 
failed to build for 32-bit SPARC with GCC mainline.

/scratch/jmyers/glibc-bot/install/compilers/sparc64-linux-gnu/lib/gcc/sparc64-glibc-linux-gnu/14.0.0/../../../../sparc64-glibc-linux-gnu/bin/ld: /scratch/jmyers/glibc-bot/install/compilers/sparc64-linux-gnu/lib/gcc/sparc64-glibc-linux-gnu/14.0.0/32/libgcc.a(_divsi3.o): in function `.div':
/scratch/jmyers/glibc-bot/src/gcc/libgcc/config/sparc/lb1spc.S:138: multiple definition of `.div'; /scratch/jmyers/glibc-bot/build/glibcs/sparcv9-linux-gnu/glibc/libc.a(sdiv.o):/scratch/jmyers/glibc-bot/src/glibc/gnulib/../sysdeps/sparc/sparc32/sparcv9/sdiv.S:13: first defined here
/scratch/jmyers/glibc-bot/install/compilers/sparc64-linux-gnu/lib/gcc/sparc64-glibc-linux-gnu/14.0.0/../../../../sparc64-glibc-linux-gnu/bin/ld: disabling relaxation; it will not work with multiple definitions
collect2: error: ld returned 1 exit status
make[3]: *** [../Rules:298: /scratch/jmyers/glibc-bot/build/glibcs/sparcv9-linux-gnu/glibc/nptl/tst-cancel24-static] Error 1

https://sourceware.org/pipermail/libc-testresults/2023q4/012154.html

I'm not sure of the exact sequence of undefined references that cause 
first the glibc object file defining .div and then the libgcc object file 
defining both .div and .udiv to be pulled in (which must have been 
perturbed by that GCC change in a way that introduced the build failure), 
but I think the failure illustrates that it's inherently fragile for glibc 
to define symbols in separate object files that libgcc defines in the same 
object file.

Should this be fixed by making glibc also define .udiv and .div together, 
or is there some better approach for fixing this build failure?  It's 
unfortunate that the division of libgcc functions into object files is 
part of the libgcc interface that glibc needs to know about (in this case, 
when glibc also defines some of the same functions), but it seems that it 
is (for static linking).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: sparcv9 build failure with GCC mainline

[Adhemerval Zanella Netto]

On 06/12/23 22:14, Joseph Myers wrote:
> Since GCC commit f31a019d1161ec78846473da743aedf49cca8c27 "Emit funcall 
> external declarations only if actually used.", the glibc testsuite has 
> failed to build for 32-bit SPARC with GCC mainline.
> 
> /scratch/jmyers/glibc-bot/install/compilers/sparc64-linux-gnu/lib/gcc/sparc64-glibc-linux-gnu/14.0.0/../../../../sparc64-glibc-linux-gnu/bin/ld: /scratch/jmyers/glibc-bot/install/compilers/sparc64-linux-gnu/lib/gcc/sparc64-glibc-linux-gnu/14.0.0/32/libgcc.a(_divsi3.o): in function `.div':
> /scratch/jmyers/glibc-bot/src/gcc/libgcc/config/sparc/lb1spc.S:138: multiple definition of `.div'; /scratch/jmyers/glibc-bot/build/glibcs/sparcv9-linux-gnu/glibc/libc.a(sdiv.o):/scratch/jmyers/glibc-bot/src/glibc/gnulib/../sysdeps/sparc/sparc32/sparcv9/sdiv.S:13: first defined here
> /scratch/jmyers/glibc-bot/install/compilers/sparc64-linux-gnu/lib/gcc/sparc64-glibc-linux-gnu/14.0.0/../../../../sparc64-glibc-linux-gnu/bin/ld: disabling relaxation; it will not work with multiple definitions
> collect2: error: ld returned 1 exit status
> make[3]: *** [../Rules:298: /scratch/jmyers/glibc-bot/build/glibcs/sparcv9-linux-gnu/glibc/nptl/tst-cancel24-static] Error 1
> 
> https://sourceware.org/pipermail/libc-testresults/2023q4/012154.html
> 
> I'm not sure of the exact sequence of undefined references that cause 
> first the glibc object file defining .div and then the libgcc object file 
> defining both .div and .udiv to be pulled in (which must have been 
> perturbed by that GCC change in a way that introduced the build failure), 
> but I think the failure illustrates that it's inherently fragile for glibc 
> to define symbols in separate object files that libgcc defines in the same 
> object file.
> 
> Should this be fixed by making glibc also define .udiv and .div together, 
> or is there some better approach for fixing this build failure?  It's 
> unfortunate that the division of libgcc functions into object files is 
> part of the libgcc interface that glibc needs to know about (in this case, 
> when glibc also defines some of the same functions), but it seems that it 
> is (for static linking).
> 


Afaik these in glibc only for compatibility reasons, and to keep the compat
was always tricky (bdc543e338281 for instance).  Consolidating .udiv and
.div on same TU seems the easiest solution.

Re: sparcv9 build failure with GCC mainline

[Joseph Myers]

On Thu, 7 Dec 2023, Adhemerval Zanella Netto wrote:

> Afaik these in glibc only for compatibility reasons, and to keep the compat
> was always tricky (bdc543e338281 for instance).  Consolidating .udiv and
> .div on same TU seems the easiest solution.

It's since occurred to me that, as these are only for compatibility and 
they only cause problems for static linking, a better fix might be to 
build them only for shared libc and let statically linked programs get the 
copies from libgcc instead.

-- 
Joseph S. Myers
joseph@codesourcery.com