[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
Mon Jan 22 12:13:20 PST 2018
compnerd added inline comments.
================
Comment at: docs/Extensions.rst:235
+
+The section is marked as ``SHF_PROGBITS`` and has the ``SHF_EXCLUDE`` flag to
+ensure that the section is treated as opaque by linkers which do not support the
----------------
jhenderson wrote:
> I think a quick example of how this would look when written in assembly would be a good idea, similar to the other code-blocks in this file.
Sure, I can add that.
================
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:
> > 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.
Repository:
rL LLVM
https://reviews.llvm.org/D40849
More information about the llvm-commits
mailing list