[Bug ipa/97119] New: Top level option to disable creation of IPA symbols such as .localalias is desired
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97119 Bug ID: 97119 Summary: Top level option to disable creation of IPA symbols such as .localalias is desired Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: ali_gccbugzilla at emvision dot com CC: marxin at gcc dot gnu.org Target Milestone: --- I work on the Solaris linkers, and in that role, often collaborate with Rainer Orth to keep gcc working on that platform. As part of that, we use gcc to build the OS along with the native Studio compilers, as a means to better test things, and because we often find that one compiler finds issues that the other doesn't. A couple of years ago (gcc 5?), we became aware of symbols ending in .localalias.nn, .part.nn, and isra.dd. While this is very impressive technology, particularly when C++ templates are generating reams of identical code bodies for various interfaces, it poses some problems for using gcc to build the core Solaris OS. To understand the issue, it is necessary to understand that Solaris has a large infrastructure dedicated to producing accurate stack traces purely from examining in memory object content (symbol tables, etc) and not relying on access to the on-disk image, or on any debug sections. Our libproc does this efficiently, and as part of that, relies on symbol sort sections generated by the linkers to map symbol names to addresses, or addresses to names. When mapping addresses to names, it is important that the name we report be the one that the programmer would understand, and not some other name that happens to have the same address, due to some under the hood optimizations. DTrace, mdb, and the ptools (pstack, etc) all rely on this. In this context, the local symbols generated by IPA, and particularly the .localalias symbols, mess up our results, causing our address-to-name tables to have multiple names, some of which are optimization implementation details that are not what the programmer would want to see. Even worse is the case where 2 functions have their bodies merged into one piece of text with 2 different names. Showing the user the "wrong" name for a function on their stack can be very misleading, and can cause wasted debugging time until they realize that they're seeing an IPA artifact. At the same time, the core OS is largely written in C, so the benefits from these particular IPA features are modest at best. We have found a few merged function bodies, and in this case, the minor duplication bloat is a price worth paying to get the correct name associated to the different instances. With previous versions of gcc, we were able to disable the production of these symbols by using -fno-ipa-icf, so we did that and moved on. With gcc10 however, we find that -fno-ipa-icf is not sufficient, and that we still see .localalias symbols in the resulting links. Although I'm sure that there is another option like -fno-ipa-icf that we could set to address that, I would like to ask for a supported way to turn off all IPA that causes symbols like these to be injected into the link. so that we can opt out for our admittedly specialized purposes, and without having to revisit it every time a new gcc version appears, or dig into the underlying optimization passes to figure out what to turn off. Please note that turning down optimization (e.g. -g) in order to achieve this isn't the sort of answer we're looking for. These are not debug objects, but rather objects built for production use. Hence we want to retain optimizations that don't generate extra symbols in a simple and maintainable way. Rainer did a one off experiment that showed that it would be fairly easy to provide this. I'll leave it to him to describe. Thanks for your consideration of this.
[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97119 --- Comment #5 from Ali Bahrami --- I added -flive-patching=inline-only-static as suggested by Martin. It didn't alter the results I'm seeing. There is still a lot of .localalias in the resulting objects. Still, the optimizations it is documented as preventing all seem like the sort of things we wouldn't want for the core OS objects, so we probably should add this. I'm at a disadvantage here, as I don't fully understand how clone functions and .localalias symbols are related. From the gcc manpage, I gather that clones are copies made to do certain optimizations, such as elimination of constant arguments. In contrast, foo, and foo.localalias seen to be references to a single function, with the main different being that foo is global and foo.localias is local. I'm not sure what the benefit of the local symbol is, but since it references the same address, as the global, it's not what I would call a clone. In any event, I would be content with a way to disable these for straightforward C objects, as opposed to specialized cases like OpenMP/OpenACC, so perhaps there's a way to do that, even if the fully general case isn't possible? Thanks. - Ali
[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97119
--- Comment #8 from Ali Bahrami ---
> 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.
[Bug ipa/97119] Top level option to disable creation of IPA symbols such as .localalias is desired
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97119 --- Comment #10 from Ali Bahrami --- > I think the issue described here are all covered by pr 63572 Can you explain how? I might not have followed it, but pr 63572 seems to revolve around generating correct DWARF content? Here, we're not reading the DWARF at all, so its correctness isn't a factor. We're not really making any claims about gcc correctness. The problem here is that what these optimizations do cause us difficulties in our simple mapping of addresses to names, while the optimizations themselves don't have enough impact to fight for. Hence, we'd like the option to opt out. - Ali
