Date: Sun, 26 Jan 2025 22:27:47 -0800 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: gcc14 static linking ends with segfault Message-ID: <Z5cnYyWxcT5pk1Wf@troutmask.apl.washington.edu> In-Reply-To: <Z5cRe8tivqpgme1I@kib.kiev.ua> References: <Z5aYNdVQdGdVImBG@troutmask.apl.washington.edu> <Z5cRe8tivqpgme1I@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Z5cnYyWxcT5pk1Wf>