[RFC] Fix for pr64706 testcase faulre

[Michael Matz]

Hello,

On Thu, 26 Mar 2020, Jan Hubicka wrote:

> > 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'm not sure I agree that it's that complicated.  With the above you 
essentially do away with the need of DECLs at all.  calls would refer to 
your fat symbols, symbols would refer to code/data bodies.  Data 
(e.g. vtables) would also refer to symbols.  Nowhere would be a DECL in 
that chain.  At that point you can just as well call your new symbols 
"DECLs".  The crucial part is merely that the DECLs/fat-symbols can change 
their association with code/data blobs.

(Well, I can see that some properties of code blobs, for instance the API, 
and hence the (function) type, is inherent to the code blob, and therefore 
should be 1to1 associated with it, some there's some argument to be made 
to retain some info of the DECL-as-now to be put tighly to the code blob 
representation).

> 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.

True.  I was just surprised by the size of this change, many diff pluses, 
few minuses :)


Ciao,
Michael.