public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "tneumann at users dot sourceforge.net" <gcc-bugzilla@gcc.gnu.org> 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 [thread overview] Message-ID: <bug-111731-4-TR7PSf1pAH@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-111731-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731 Thomas Neumann <tneumann at users dot sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #57679|0 |1 is obsolete| | --- Comment #18 from Thomas Neumann <tneumann at users dot sourceforge.net> --- Created attachment 57692 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57692&action=edit 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 placing 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 must 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 would make frame registration more expensive (even though lookup became faster, because we would no longer have to traverse the object).
next prev parent reply other threads:[~2024-03-14 6:49 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-10-09 2:17 [Bug libgcc/111731] New: " crazylht at gmail dot com 2023-10-09 2:18 ` [Bug libgcc/111731] " crazylht at gmail dot com 2023-10-09 2:20 ` crazylht at gmail dot com 2023-10-09 9:57 ` rguenth at gcc dot gnu.org 2024-03-11 11:51 ` dimitar.yordanov at sap dot com 2024-03-11 12:03 ` tneumann at users dot sourceforge.net 2024-03-11 12:41 ` dimitar.yordanov at sap dot com 2024-03-11 12:55 ` dimitar.yordanov at sap dot com 2024-03-11 12:58 ` tneumann at users dot sourceforge.net 2024-03-11 12:59 ` dimitar.yordanov at sap dot com 2024-03-11 13:02 ` tneumann at users dot sourceforge.net 2024-03-11 13:39 ` dimitar.yordanov at sap dot com 2024-03-11 13:45 ` tneumann at users dot sourceforge.net 2024-03-11 14:10 ` dimitar.yordanov at sap dot com 2024-03-11 18:00 ` jakub at gcc dot gnu.org 2024-03-11 19:52 ` tneumann at users dot sourceforge.net 2024-03-12 6:27 ` tneumann at users dot sourceforge.net 2024-03-12 6:29 ` liuhongt at gcc dot gnu.org 2024-03-13 17:57 ` dimitar.yordanov at sap dot com 2024-03-14 6:48 ` tneumann at users dot sourceforge.net [this message] 2024-03-15 9:14 ` dimitar.yordanov at sap dot com 2024-03-22 14:08 ` cvs-commit at gcc dot gnu.org 2024-04-02 8:37 ` cvs-commit at gcc dot gnu.org 2024-04-02 11:24 ` rguenth at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-111731-4-TR7PSf1pAH@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).