[Bug ipa/97119] New: Top level option to disable creation of IPA symbols such as .localalias is desired

["ali_gccbugzilla at emvision dot com" <gcc-bugzilla@gcc.gnu.org>]

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.