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.
