public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* Do not build sparc32 libgcc functions into static libc
@ 2023-12-07 20:11 Joseph Myers
  2023-12-13 22:16 ` Ping " Joseph Myers
  2023-12-19 15:54 ` Adhemerval Zanella Netto
  0 siblings, 2 replies; 3+ messages in thread
From: Joseph Myers @ 2023-12-07 20:11 UTC (permalink / raw)
  To: libc-alpha

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 - and indeed for glibc to
redefine libgcc symbols at all, since the division into object files
shouldn't really be part of the interface between libgcc and libc.

These symbols appear to be in libc only for compatibility, maybe one
of the cases where they were accidentally exported from shared libc in
glibc 2.0 before the introduction of symbol versioning and so programs
started expecting shared libc to provide them.  Thus, there is no need
to have them in static libc.  Add this set of libgcc functions to
shared-only-routines so they are no longer provided in static libc.
(No change is made regarding .mul - dotmul source file - since unlike
the other symbols in this grouping, it doesn't actually appear to be a
libgcc symbol, at least in current GCC.)

Tested with build-many-glibcs.py for sparcv9-linux-gnu with GCC
mainline.

diff --git a/sysdeps/sparc/sparc32/Makefile b/sysdeps/sparc/sparc32/Makefile
index b792e56710..cc1db68cc6 100644
--- a/sysdeps/sparc/sparc32/Makefile
+++ b/sysdeps/sparc/sparc32/Makefile
@@ -17,6 +17,7 @@
 
 ifeq ($(subdir),gnulib)
 sysdep_routines = dotmul umul $(divrem) alloca
+shared-only-routines += umul $(divrem)
 endif	# gnulib
 
 divrem := sdiv udiv rem urem

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Ping Re: Do not build sparc32 libgcc functions into static libc
  2023-12-07 20:11 Do not build sparc32 libgcc functions into static libc Joseph Myers
@ 2023-12-13 22:16 ` Joseph Myers
  2023-12-19 15:54 ` Adhemerval Zanella Netto
  1 sibling, 0 replies; 3+ messages in thread
From: Joseph Myers @ 2023-12-13 22:16 UTC (permalink / raw)
  To: libc-alpha

Ping.  This patch 
<https://sourceware.org/pipermail/libc-alpha/2023-December/153227.html> is 
pending review.

-- 
Joseph S. Myers
joseph@codesourcery.com

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Do not build sparc32 libgcc functions into static libc
  2023-12-07 20:11 Do not build sparc32 libgcc functions into static libc Joseph Myers
  2023-12-13 22:16 ` Ping " Joseph Myers
@ 2023-12-19 15:54 ` Adhemerval Zanella Netto
  1 sibling, 0 replies; 3+ messages in thread
From: Adhemerval Zanella Netto @ 2023-12-19 15:54 UTC (permalink / raw)
  To: Joseph Myers, libc-alpha



On 07/12/23 17:11, 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 - and indeed for glibc to
> redefine libgcc symbols at all, since the division into object files
> shouldn't really be part of the interface between libgcc and libc.
> 
> These symbols appear to be in libc only for compatibility, maybe one
> of the cases where they were accidentally exported from shared libc in
> glibc 2.0 before the introduction of symbol versioning and so programs
> started expecting shared libc to provide them.  Thus, there is no need
> to have them in static libc.  Add this set of libgcc functions to
> shared-only-routines so they are no longer provided in static libc.
> (No change is made regarding .mul - dotmul source file - since unlike
> the other symbols in this grouping, it doesn't actually appear to be a
> libgcc symbol, at least in current GCC.)
> 
> Tested with build-many-glibcs.py for sparcv9-linux-gnu with GCC
> mainline.
> 
> diff --git a/sysdeps/sparc/sparc32/Makefile b/sysdeps/sparc/sparc32/Makefile
> index b792e56710..cc1db68cc6 100644
> --- a/sysdeps/sparc/sparc32/Makefile
> +++ b/sysdeps/sparc/sparc32/Makefile
> @@ -17,6 +17,7 @@
>  
>  ifeq ($(subdir),gnulib)
>  sysdep_routines = dotmul umul $(divrem) alloca
> +shared-only-routines += umul $(divrem)
>  endif	# gnulib
>  
>  divrem := sdiv udiv rem urem
> 

LGTM, thanks.

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-12-19 15:54 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-12-07 20:11 Do not build sparc32 libgcc functions into static libc Joseph Myers
2023-12-13 22:16 ` Ping " Joseph Myers
2023-12-19 15:54 ` Adhemerval Zanella Netto

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).