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

Saleem Abdulrasool via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jan 24 11:13:51 PST 2018


compnerd marked 2 inline comments as done.
compnerd added inline comments.


================
Comment at: tools/llvm-readobj/ELFDumper.cpp:4085-4086
+    if (Name != ".linker-options")
+      continue;
+
+    ArrayRef<uint8_t> Contents = unwrapOrError(Obj->getSectionContents(&Shdr));
----------------
jhenderson wrote:
> compnerd wrote:
> > jhenderson wrote:
> > > compnerd wrote:
> > > > ruiu wrote:
> > > > > It is one of the design principles of ELF that section names are not significant. Section should be identified by type and not by name. Can you define a new section type and use it?
> > > > As long as we are sure that this won't cause any issues with the BFD and gold linkers, I would be fine with that.  Unfortunately, compatibility needs to be considered here.
> > > I agree that a new type would be nice. I did some playing around with gold and BFD, and gold can handle unknown section types without complaint, whereas BFD cannot. The exception is that BFD accepts section types reserved for user applications (between SHT_LOUSER and SHT_HIUSER), and those reserved for OS-specific sections (i.e. in the SHT_LOOS to SHT_HIOS) (there are irrelevant exceptions based on the flags). Neither of these look like ideal solutions.
> > > 
> > > Maybe this is worth discussion on the gABI and/or BFD mailing list, on the more general topic of "we want to extend ELF, at least for our linker/compiler pair. What section type should we use?"
> > I can create a custom section type in the reserved range I suppose.
> My problem is that I don't know which reserved range is the right one to use. There doesn't seem to be a "vendor" reserved range. LLVM isn't an OS, Processor, or final application, which are what the three current ranges refer to.
I just added it to the same area as the ODR table extension.


Repository:
  rL LLVM

https://reviews.llvm.org/D40849





More information about the llvm-commits mailing list