From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E8E77385841E; Thu, 14 Mar 2024 06:49:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E8E77385841E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1710398940; bh=c4noL9H8pM+yqoZjfyLdvUG0BWzgkOAdfYp3NEJ0VoQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Ay1u0Sxz69hEV6xweUGJIGMtocrn0IOi5fFflU2e9bObFVOttSHZhwup3lcDhFs2F wa61JFrlsM8n2VKD/OLMtQSjTw+hEcGPvhgUgNjs3Iqzxum3/BgerudgMVYdXZGsiq q+FqvNfpaR+5G/DGk1q2Cf+EuJAa5neyhre1mQrE= From: "tneumann at users dot sourceforge.net" To: gcc-bugs@gcc.gnu.org Subject: [Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291 Date: Thu, 14 Mar 2024 06:48:59 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libgcc X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: tneumann at users dot sourceforge.net X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created 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=3D111731 Thomas Neumann changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #57679|0 |1 is obsolete| | --- Comment #18 from Thomas Neumann = --- Created attachment 57692 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D57692&action=3Dedit patch with separate btrees We will have to do that, I have updated the patch to use a separate lookup structure for the tables. Which prevents the original problem and hopefully fixes the issue. The only thing that makes me nervous is that if some JITer comes up with the idea of placing an unwind tuple inside some code range, what prevents them from pla= cing code from one table within code from another table? Which would break the assumption that code ranges do not overlap. Note that the non-fast-path code also makes the assumption that code ranges= do not overlap, see the comment in _Unwind_Find_FDE. Thus perhaps no JIT code emitter will do that. But if somebody does we should probably store the fde instead of the object inside the lookup structure. The fde ranges really mu= st not overlap, otherwise everything breaks. But I would like to not do that because we have more fdes than objects and storing each fde individually wo= uld make frame registration more expensive (even though lookup became faster, because we would no longer have to traverse the object).=