[PATCH] D40849: CodeGen: support an extension to pass linker options on ELF

Wed Dec 20 19:25:07 PST 2017

compnerd added a comment.

In https://reviews.llvm.org/D40849#961429, @silvas wrote:

> It looks like this thread has evolved into a design discussion. It isn't clear to me that we all agree on what problem should be solved. Saleem, it seems like you have some interest in having the format be open-ended, while many others (myself included) seem to want this to be as locked-down as possible with a narrow set of really clearly defined operations. Saleem, could you maybe start an RFC on llvm-dev so we can have a higher-level design discussion? Off the top of my head, there are a couple things that have been mentioned in this thread but not really resolved:

Sure, I can start a thread there.  However, I really was hoping to get this in for the release.  It really would help with swift.

> - Should we discuss this with bfd and gold? If not, why not?

Sure, if we can actually emit this, I think that bringing it up to them is reasonable, and good.

> - I know the PlayStation proprietary linker has support for a similar feature (as James has been discussing) and IIRC there were private patches in the compiler for it. Is it in scope for this change to allow deleting those private patches from the PlayStation compiler?

Yes, I want this to be sufficiently generic that they would be able to rely on the functionality provided here to implement their support.  However, in either case, I don't think that the backend should be involved in understanding the options at all.  This is not the proper change to discuss that IMO.

> - How does this interact with the similar functionality on COFF and MachO? Is it in scope to have a common IR representation for the three platforms?

I'm not sure what you mean by interact with them.  It is implementing the same functionality.  Yes, the implementation here is designed to ensure that the IR representation is identical across the three platforms.  Right now, the COFF and MachO IR level representation is the same, and I did ensure that the same held for ELF.  The content of the node is what changes across the implementations, because the option is linker dependent.

> - From my reading of the spec, SHT_NOTE is optional. But presumably information like extra library paths is actually semantically necessary for obtaining a correct link and must not be dropped. This also is related to the question of representing this as metadata in the IR.

Yes, that is correct, SHT_NOTE support is optional.  That is why this is designed to be represented as a note.  It allows linkers which do not support the feature to still work with the object file and still ensure that the object content does not make it into the final binary (it is supposed to be dropped).  AIUI, any conforming implementation will drop the note even within a whole archive case.

Repository:
  rL LLVM

https://reviews.llvm.org/D40849