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:21:14 +0000	[thread overview]
Message-ID: <bug-110956-4-8aldgVav8F@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 #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jeff Law <law@gcc.gnu.org>:

https://gcc.gnu.org/g:c46bded78f3733ad1312d141ebf1ae541032a48b

commit r14-3154-gc46bded78f3733ad1312d141ebf1ae541032a48b
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.

  parent reply	other threads:[~2023-08-11 15:21 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 [this message]
2023-08-11 15:29 ` cvs-commit at gcc dot gnu.org
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-8aldgVav8F@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: link
Be 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).