[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
[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 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=63572 --- Comment #9 from Andrew Pinski --- I think the issue described here are all covered by pr 63572
[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 #7 from Jan Hubicka --- Local aliases are created by ipa-visibility pass. Most common case is that function is declared inline but ELF superposition rules say that the symbol can be overwritten by a different library. Since GCC knows that all implementaitons must be equivalent, it can force calls within DSO to be direct. I am not quite sure how this confuses stack unwinding on Solaris? For live patching, if you want to patch inline function, one definitely needs to look for places it has been inlined to. However in the situation the function got offlined, I think live patching should just work, since it will place jump in the beggining of function body. The logic for creating local aliases is in ipa-visibility.cc. Adding command line option to control it is not hard. There are other transformations we do there - like breaking up comdat groups and other things. part aliases are controlled by -fno-partial-inlining, isra by -fno-ipa-sra. There is also ipa-cp controlled by -fno-ipa-prop. We also do alises as part of openMP offlining and LTO partitioning that are kind of mandatory (there is no way to produce correct code without them).
[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 #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- 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've since compared the list of options disabled by -flive-patching=inline-only-static with the call sites of noninterposable_alias and the options that controlled their use. I'd initially done this to come up with additional options to try on top of -fno-ipa-icf that Ali had been using. This identified two more to try: -fdevirtualize -fipa-profile However, Ali found that disabling those doesn't help either. Any additional suggestions what else to try here? > 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. This is still an important issue, I believe: without fully understanding what those symbols are needed for and what the consequences would be of disabling their creation, it's hard to decide what to do. Going back to my initial hack (attached) of disabling .localalias* creation, what it does is exactly what happens on targets that don't define ASM_OUTPUT_DEF, i.e. don't support aliases. At least a testsuite run identified almost no impact (one failing test on Solaris/x86). Given that this is a supported configuration, I'd expect that this doesn't result in wrong code. Would a patch along those lines (properly controlled by an off-by-default option) be acceptable to move this forward?
[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 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- There is no way to turn all of these, and I'm afraid can't be. E.g. for the OpenMP/OpenACC outlined bodies of constructs, they need to be named somehow. Sure, one can disable many other ways how to clone functions (e.g. effectively imply all functions have noclone attribute), but it will not handle everything.
[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 #3 from Rainer Orth --- (In reply to Ali Bahrami from comment #0) > 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. Right: initially I looked around trying to find a set of options to turn off generation of those .localalias* symbols, but was unable to find any. In an experiment to assess any testsuite impact of disabling their generation, I came up with the attached hack. It passed sparc-sun-solaris-2.11 testing without regressions, while on amd64-pc-solaris2.11 there was a single regression: +FAIL: gcc.dg/pr56727-1.c scan-assembler-not @(PLT|plt) (32-bit only).
[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 #2 from Rainer Orth --- Created attachment 49246 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49246=edit Hack to disable .localalias* generation
[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 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-09-21 --- Comment #1 from Martin Liška --- You likely want to disable all IPA optimizations that create clones. Probably the same what -flive-patching=inline-only-static does? Please see a man page for the -flive-patching option.
