From nobody Mon Jan 27 17:52:34 2025 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Yhbbs3vvQz5m1mv for ; Mon, 27 Jan 2025 17:52:41 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Yhbbs1TyXz3kD8; Mon, 27 Jan 2025 17:52:41 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Authentication-Results: mx1.freebsd.org; none Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.18.1/8.18.1) with ESMTP id 50RHqYur004924; Mon, 27 Jan 2025 09:52:39 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) DKIM-Filter: OpenDKIM Filter v2.10.3 troutmask.apl.washington.edu 50RHqYur004924 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=troutmask.apl.washington.edu; s=troutmask; t=1738000359; bh=FJfqjX+hn9yVsPkc4ehzZXvxLv3Mm9yhtIgzrlYzLJc=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=qXY5hAJ774ry8VhImcQIMI7tk2Iw3apOzx1GVPZc7Py7aBs/hIrVfJ/0nctT7jXk1 939V3k++jmI/iyqVLdDxC9VyyLOQp6snu62MSwXnaYc8XmGUbDdciSrszWx5jixY74 EjPqT/+M9nGnhwVlsXh3UgqNnMKvMqnLsWCs53zBi4vbdUIoTjEtAkhtv7ONV78iyN u60quQxlsYhJu4RKpFIRnoQLUpW4n5/B27DWUdeYMmKI+aNNXirF2ebpNmfcR1oR8k mxoxVZMXoKWmk2G/aCO/37uG7xN3mhn5/XxnqndIcs0GUPJ3gcd3eOKpF+ddqw8yuK UM8QNT6P4Kpkw== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.18.1/8.18.1/Submit) id 50RHqYwg004923; Mon, 27 Jan 2025 09:52:34 -0800 (PST) (envelope-from sgk) Date: Mon, 27 Jan 2025 09:52:34 -0800 From: Steve Kargl To: Dimitry Andric Cc: Konstantin Belousov , freebsd-hackers@freebsd.org Subject: Re: gcc14 static linking ends with segfault Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Yhbbs1TyXz3kD8 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US] On Mon, Jan 27, 2025 at 04:34:22PM +0100, Dimitry Andric wrote: > On 27 Jan 2025, at 07:27, Steve Kargl wrote: > > > > 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 > >>> #include > >>> #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); > >>> } (remove some unimportant info) > >>> 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=, mainX=0x400515
) > > 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. > > The sqr_basecase.s thing is a red herring. In fact, the whole mpfr/gmp > thing is a red herring. :) The actual problem is in the way gcc emits > the .dtors section: > > $ readelf --hex-dump=.dtors static-test-clang > > Hex dump of section '.dtors': > 0x004f3d30 ffffffff ffffffff 00000000 00000000 ................ > > $ readelf --hex-dump=.dtors static-test-gcc > > Hex dump of section '.dtors': > 0x004efca8 ffffffff ffffffff ........ > (Debugging info removed to keep this short) > > During gcc's configure phase, I see: > > checking for .preinit_array/.init_array/.fini_array support... yes > > so initfini_array support is then enabled. I tried building gcc14 with --enable-initfini-array configure option. Maybe I should try --disable-initfini-array. > In libgcc's crtstuff.c, which is used to generate crtbegin.o and > crtend.o, the definitions of .ctors and .dtors are all conditional on > #ifndef USE_INITFINI_ARRAY. This is why gcc's crtbegin.o and crtend.o > only have .init and .fini sections, but no .ctors or .dtors. Thanks for the thorough explanation! You've given me someplace to poke around in crtstuff.c. I do see in gcc/config/freebsd-spec.h /* Provide a STARTFILE_SPEC appropriate for FreeBSD. Here we add the magical crtbegin.o file (see crtstuff.c) which provides part of the support for getting C++ file-scope static object constructed before entering `main'. */ #define FBSD_STARTFILE_SPEC \ "%{!shared: \ %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} \ %{!p:%{profile:gcrt1.o%s} \ %{!profile: \ %{pie: Scrt1.o%s;:crt1.o%s}}}}} \ crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}" /* Provide a ENDFILE_SPEC appropriate for FreeBSD. Here we tack on the magical crtend.o file (see crtstuff.c) which provides part of the support for getting C++ file-scope static object constructed before entering `main', followed by a normal "finalizer" file, `crtn.o'. */ #define FBSD_ENDFILE_SPEC \ "%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s" So, the paths must be dealt with by crtstuff.c. -- Steve