Re: gcc14 static linking ends with segfault

On Mon, Jan 27, 2025 at 06:54:19AM +0200, Konstantin Belousov wrote:
> On Sun, Jan 26, 2025 at 12:16:53PM -0800, Steve Kargl wrote:
> > In replacing an ancient system with new I re-installed all ports
> > including lang/gcc14 of FreeBSD-current.  -current is 2 day old
> > sources.
> > 
> > Consider,
> > 
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include "mpfr.h"
> > 
> > int
> > main(void)
> > {
> >    mpfr_t pi;
> >    mpfr_inits2(512, pi, NULL);
> >    mpfr_const_pi(pi, MPFR_RNDN);
> >    mpfr_printf("pi = %25.20Rf\n", pi);
> > // A conscientious programmer cleans up after themself,
> > // but on exit the system should take care of memory.
> > //   mpfr_clears(pi, NULL);
> >    return (0);
> > }
> > 
> > % gcc14 -o z -O2 -I/usr/local/include a.c -L/usr/local/lib -lmpfr -lgmp
> > % ./z
> >  pi =    3.14159265358979323846
> > 
> > All seems to work with shared linking.
> > 
> > The following used to work.
> > 
> > % gcc14 -o z -O2 -I/usr/local/include a.c -L/usr/local/lib -lmpfr -lgmp \ 
> >         -static
> > % ./z
> > pi =    3.14159265358979323846
> > Segmentation fault (core dumped)
> > 
> > % gdb151 ./z z.core 
> > ...
> > #0  0x0000000000427ba5 in __gmpn_mul_1 ()
> > (gdb) bt
> > #0  0x0000000000427ba5 in __gmpn_mul_1 ()
> > #1  0x000000000040051f in __do_global_dtors_aux ()
> >     at /usr/src/lib/csu/common/crtbegin.c:83
> > #2  0x00000000004bc165 in _fini ()
> > #3  0x0000000000458a7f in __cxa_finalize (dso=dso@entry=0x0)
> >     at /usr/src/lib/libc/stdlib/atexit.c:234
> > #4  0x0000000000458b70 in exit (status=0) at /usr/src/lib/libc/stdlib/exit.c:89
> > #5  0x00000000004483d9 in __libc_start1 (argc=1, argv=0x820a52900, 
> >     env=0x820a52910, cleanup=<optimized out>, mainX=0x400480 <main>)
> >     at /usr/src/lib/libc/csu/libc_start1.c:172
> > #6  0x00000000004004f0 in _start () at /usr/src/lib/csu/amd64/crt1_s.S:83
> > 
> > So, did someone break the startup files?
> Why do you think that startup (crt) files are broken?
> Note that they are involved in the trace above, but the lowest frame is
> from gmp destructor, i.e. the problem formally happens in the gmp code.
> 
> Perhaps try to rebuild gmp with debug info to get more information.

You likely correct that its a gmp problem unmasked by the
new hardware that I have.  Rebuilding gmp with debugging
did not help :(

(gdb) run
...
Program received signal SIGSEGV, Segmentation fault.
Address not mapped to object.
__gmpn_sqr_basecase () at tmp-sqr_basecase.s:222
warning: 222    tmp-sqr_basecase.s: No such file or directory
(gdb) bt
#0  __gmpn_sqr_basecase () at tmp-sqr_basecase.s:222
#1  0x00000000004004df in __do_global_dtors_aux ()
    at /usr/src/lib/csu/common/crtbegin.c:83
#2  0x00000000004c8875 in _fini ()
#3  0x000000000046518f in __cxa_finalize (dso=dso@entry=0x0)
    at /usr/src/lib/libc/stdlib/atexit.c:234
#4  0x0000000000465280 in exit (status=0) at /usr/src/lib/libc/stdlib/exit.c:89
#5  0x0000000000454ae9 in __libc_start1 (argc=1, argv=0x7fffffffe738, 
    env=0x7fffffffe748, cleanup=<optimized out>, mainX=0x400515 <main>)
    at /usr/src/lib/libc/csu/libc_start1.c:172
#6  0x00000000004004b0 in _start () at /usr/src/lib/csu/amd64/crt1_s.S:83

It seems gmp's build infrastructure removes tmp files. 


-- 
Steve