From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A7A233858D39; Tue, 14 Mar 2023 07:04:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A7A233858D39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1678777495; bh=ounr4AKI1WDLGHAFkaFTuSVn1yFavXPDxo1oJUTeQFM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UHzaZfSKZmh3WTrmU1E21LLoHR+YzLBD9TmACOjVLHwZ7Wckjv2b+0L2im0b+U8IR DrbiBhGar94gycoK4Y7phTqeZVZ9adcdtHQl7vwHfEAbUdWuA5TplJevXfsBiCggB3 hytadndhEZNCMUdJzwd9vqezalIE5yWmV1+nN08U= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1 since r13-2706-g6e80a1d164d1f9 Date: Tue, 14 Mar 2023 07:04:55 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108994 --- Comment #18 from Jakub Jelinek --- It is a fundamental assumption that the FDE/CIE chain is zero terminated, a= fter all, all the registration APIs (__register_frame_table, __register_frame_info_table, __register_frame_info_table_bases) take just a begin pointer, not a begin and end pointer nor begin + count or something similar, nor assume there is just one FDE (after all, a FDE needs some CIE,= so there would need to be a routine that expects exactly two or something similar). When not using .eh_frame_hdr (which is used most of the time on glibc since= end of 2001 when I've added it and somewhat later on Solaris etc.), crtbegin.o/crtend.o ensures this, crtbegin.o provides a label at the start = of .eh_frame and is linked first among the objects: /* Stick a label at the beginning of the frame unwind info so we can regist= er and deregister it with the exception handling library code. */ STATIC EH_FRAME_SECTION_CONST char __EH_FRAME_BEGIN__[] __attribute__((section(__LIBGCC_EH_FRAME_SECTION_NAME__), aligned(4))) =3D { }; while crtend.o provides the zero termination: /* Terminate the frame unwind info section with a 4byte 0 as a sentinel; this would be the 'length' field in a real FDE. */ # if __INT_MAX__ =3D=3D 2147483647 typedef int int32; # elif __LONG_MAX__ =3D=3D 2147483647 typedef long int32; # elif __SHRT_MAX__ =3D=3D 2147483647 typedef short int32; # else # error "Missing a 4 byte integer" # endif STATIC EH_FRAME_SECTION_CONST int32 __FRAME_END__[] __attribute__ ((used, section(__LIBGCC_EH_FRAME_SECTION_NAME__), aligned(__alignof__(int32)))) =3D { 0 }; and is linked last. I believe LLVM does the same thing in compiler-rt/lib/crt/crtbegin.c and compiler-rt/lib/crt/crtend.c . If you readelf -wf any_binary_or_library it should show 00330010 ZERO terminator line (with whatever address) at the end.=