public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libgcc/110956] [13/14 regression] gcc_assert is hit at gcc-13.2.0/libgcc/unwind-dw2-fde.c#L291 with some special library Date: Fri, 11 Aug 2023 15:29:12 +0000 [thread overview] Message-ID: <bug-110956-4-L5gdkSVdMX@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-110956-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956 --- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-13 branch has been updated by Jeff Law <law@gcc.gnu.org>: https://gcc.gnu.org/g:ab8fed849ab345974e5b83472749ac1393878f71 commit r13-7709-gab8fed849ab345974e5b83472749ac1393878f71 Author: Thomas Neumann <thomas.neumann@in.tum.de> Date: Fri Aug 11 09:20:27 2023 -0600 preserve base pointer for __deregister_frame [PR110956] Original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110956 Rainer Orth successfully tested the patch on Solaris with a full bootstrap. Some uncommon unwinding table encodings need to access the base pointer for address computations. We do not have that information in calls to __deregister_frame_info_bases, and previously simply used nullptr as base pointer. That is usually fine, but for some Solaris i386 shared libraries that results in wrong address computations. To fix this problem we now associate the unwinding object with the table pointer itself, which is always known, in addition to the PC range. When deregistering a frame, we first locate the object using the table pointer, and then use the base pointer stored within the object to compute the PC range. libgcc/ChangeLog: PR libgcc/110956 * unwind-dw2-fde.c: Associate object with address of unwinding table.
next prev parent reply other threads:[~2023-08-11 15:29 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-08-09 7:33 [Bug libgcc/110956] New: " sumbera at volny dot cz 2023-08-09 10:40 ` [Bug libgcc/110956] " tneumann at users dot sourceforge.net 2023-08-09 11:09 ` ro at gcc dot gnu.org 2023-08-09 11:15 ` [Bug libgcc/110956] [13, 14 regression] " ro at gcc dot gnu.org 2023-08-09 11:18 ` ro at gcc dot gnu.org 2023-08-09 13:40 ` [Bug libgcc/110956] [13/14 " rguenth at gcc dot gnu.org 2023-08-09 13:53 ` tneumann at users dot sourceforge.net 2023-08-09 17:02 ` ro at manam dot mail-host-address-is-not-set 2023-08-09 22:55 ` tneumann at users dot sourceforge.net 2023-08-10 6:49 ` tneumann at users dot sourceforge.net 2023-08-10 8:44 ` ro at CeBiTec dot Uni-Bielefeld.DE 2023-08-10 11:11 ` ro at CeBiTec dot Uni-Bielefeld.DE 2023-08-11 15:21 ` cvs-commit at gcc dot gnu.org 2023-08-11 15:29 ` cvs-commit at gcc dot gnu.org [this message] 2023-10-09 9:57 ` rguenth at gcc dot gnu.org 2024-03-10 3:46 ` law 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-110956-4-L5gdkSVdMX@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).