> > Is it? What does a non-weak local alias to a weak function mean? > > I think we should continue to try to model ELF semantics re weak and > aliases. If so, then yes, LTO gets it wrong and the above testcase should > not abort. Weak doesn't enter the picture for creating aliases (the > aliases is created with the declaration, and we require an available > definition, and the alias is henceforth bound to _that_ very definition). > I.e. the 'a.c:b' name should continue to refer to the same code snippet > identified by the a.c:a name, not be redirected to the overriding b.c:a. > > I'm wondering about the amount of code necessary to fix this. I think > that points towards a wrong level of representation somewhere, and perhaps > _that_ should be changed instead of trying to work around it. > > For instance, right now aliases are different from non-aliases, whereas in > reality there's no difference: there are simply names referring to code or > data snippets, and it so happens that for some snippets there are multiple > names, and it further just so happens that some names for a code snippet > become overridden/removed by other names for other code snippets, which > doesn't invalidate the fact that there still is another name for the first > snippet. > > If it were modelled like that in cgraph/lto all the rest would naturally > follow. (Of course you would need tracking of when some code/data > snippets can't be referred to by name anymore (and hence are useless), > because all names for them went away, or none of the existing names is > used anymore, but I don't think that materially would change much in our > internal data structures).
Yep, the trouble is caused by fact that GCC representation is not quite what linker does. I.e. we bind function bodies with their declarations and declarations with symbols. We are bouit about assumption of 1to1 correspondence between function bodies and their symbols. This is not true because one body may have multiple aliases but also it may define mutliple different symbols (alternative entry points & labels). Reorganizing this design is quite some work. We need to change trees/GIMPLE to use symbols instead of DECLs when referring to them. So parameter of CALL_EXPR would not be decl but symbol associated with it. We to move everyting that is property of symbol away from decl into symbols (i.e. assembler name, visibility, section etc) and thus we would need to change everything from frontends all the way to RTL. I am gradually shuffling things in this direction (I plan to move assembler names to symbols and gradually do that for visibilitie so we can have cross-module referneces to labels and finally support static initializers taking addresses of them), but the process is slow and I think it makes sense to first fix correctness issues with what we have rahter than waiting for major surgery to be finished. Honza > > > Ciao, > Michael.
