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

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

The current elf gABI says that we should be using 8-byte alignment for 64-bit objects, not 4-byte alignment, so I think that this code needs updating for that case. However, I gather from an ongoing discussion on the gABI mailing lists that this has been inconsistently applied, and I haven't looked to see what LLVM does for other .note sections, so I would advise doing whatever is consistent with other LLVM-emitted .note sections.

I have two possible thoughts based on @ruiu's comments, which are effectively competing approaches:

1. Why not explicitly define now types for the specific use cases already known about, e.g. one for adding libraries, and one for adding library paths? Then, instead of this being arbitrary option strings, the desc becomes the name of the library/path that should be added.
2. Linkers could simply reject/ignore any directives received that make no sense for that specific linker (they could make more sense for other linkers, depending on their design).

I personally prefer option 1), as it better matches what our proprietary linker does, and will make it easier to port things! Also, it makes things a little easier to control, I think. Option 2) though is perhaps more flexible for different linkers to support - it may be, for example, that some options make perfect sense for some linkers and not for others, though there's no reason why LLD and other linkers couldn't just reject/ignore unrecognised/unsupported types. Option 2) also allows for the compiler to remain agnostic, as you described, which leads me onto my next question:

How do you anticipate end-users making use of this functionality? Is it via command-line options? Source code additions? Something else that I haven't thought of? I think the mechanism used might inform the design choice above. For example, if the mechanism is to do it via different kinds of pragmas (e.g. `#pragma comment(lib, "mylib.a" and #pragma comment(libpath, "/some/library/path")`, I think option 1) starts to make more sense again - to increase the set of options that this supports would require adding new pragma options, so it requires modifying the compiler anyway. If, on the other hand, it's more like a single pragma that provides a raw command-line (e.g. `#pragma comment(linker, "-lmylib.a -L/some/lib/path", or better yet, two different pragma lines one for each option, to avoid having to parse the string)`, then clearly option 2) makes more sense. In either case, the linker is likely to need updating to support the new option that is desired, since we want to restrict what the linker will attempt to use, or we could get very broken links.



================
Comment at: lib/CodeGen/TargetLoweringObjectFileImpl.cpp:119
+    Streamer.EmitIntValue(0, 1);
+  }
+
----------------
For a valid note section, you also need to align the end of the desc field.


================
Comment at: test/Feature/elf-linker-options.ll:1
+; RUN: llc -mtriple i686-unknown-linux-gnu -filetype asm -o - %s | FileCheck %s
+
----------------
Could we have a 64-bit test-case, as well, please?


Repository:
  rL LLVM

https://reviews.llvm.org/D40849