public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ali_gccbugzilla at emvision dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired
Date: Fri, 02 Feb 2024 22:42:06 +0000	[thread overview]
Message-ID: <bug-97119-4-YmGOlyZz6x@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-97119-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97119

--- Comment #8 from Ali Bahrami <ali_gccbugzilla at emvision dot com> ---
> I am not quite sure how this confuses stack unwinding on Solaris?

I don't think that most of what you described is a problem
for stack unwinding on Solaris. As discussed in the initial
note, the problem is that we use a table that maps address to
function names ("sort sections") to map virtual addresses to
symbols, and then use those symbol names for the stack
trace. The localalias, and similar, symbols that gcc is
producing make trouble for us, in a couple of ways:

    (1) Since these symbols have the same addresses as the
        original functions, they might show up in the stack
        trace output, rather than the "real" name that the
        programmer used.

    (2) In the case where gcc replaces multiple identical
        function bodies with one instance, the original 1:1
        relationship between name and address is lost. Imagine
        that my code has functions fooA() and fooB() that get
        collapsed into one body, and now, both functions have
        the same address. My stack traces may show one when the
        programmer actually called the other.

(1) is just an annoyance. (2) is a bit more serious, since
conceptually, fooA() and fooB() really are different, and the
programmer really should see a stack that reflects what their
source code says.

As to why this is done, it's a way to get a useful
stack trace for code that has no debug sections, or
in contexts where running a debugger to get a trace
isn't possible. We put a high priority on observabilty
in contexts where debug sections are not available, or
running a debugger is not possible.

As I hope was clear in my original note, we think these gcc
optimizations are very useful for lots (maybe most) code,
but for our very simple C code base, the win is small, and
the negative aspects are a problem. It would be very useful
for us if this class of optimization could be disabled with
a simple switch.

We filed this request almost 4 years ago, and seeing that it
wasn't getting traction, I've since modified our link-editor
to drop all symbols of the form

    XXX.isra.dd
    XXX.localalias.dd
    XXX.part.dd

from the sort sections. It's an effective hack against
problem (1) above, though not (2). It's also not how
linking ought to work: hardwiring and checking the names
of symbols produced by a specific compiler as a side effect
of optimization settings is ugly and error prone. I'd love
to rip it out if we can get back to gcc producing the 1:1
symbol to code address relationship.

Let me know if more explanation is needed. Thanks.

  parent reply	other threads:[~2024-02-02 22:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-18 23:22 [Bug ipa/97119] New: " ali_gccbugzilla at emvision dot com
2020-09-21 11:19 ` [Bug ipa/97119] " marxin at gcc dot gnu.org
2020-09-21 14:12 ` ro at gcc dot gnu.org
2020-09-21 14:12 ` ro at gcc dot gnu.org
2020-09-21 14:28 ` jakub at gcc dot gnu.org
2020-09-21 19:18 ` ali_gccbugzilla at emvision dot com
2020-09-25  9:20 ` ro at CeBiTec dot Uni-Bielefeld.DE
2024-02-02 10:33 ` hubicka at gcc dot gnu.org
2024-02-02 22:42 ` ali_gccbugzilla at emvision dot com [this message]
2024-02-02 22:48 ` pinskia at gcc dot gnu.org
2024-02-03  1:40 ` ali_gccbugzilla at emvision dot com

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-97119-4-YmGOlyZz6x@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).