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

Rui Ueyama via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 8 16:02:43 PST 2017


ruiu added a comment.

Do you mind if I ask you explain the motivation of adding this feature?

COFF linkers support somewhat similar feature. For COFF, you can embed a string containing linker command line options in a .drctive section, and if a linker decide to link that object file, it handles the command line options as if they were given via the command line. The feature is used, for example, to add "/lib" option (-l in Unix) to the command line automatically, so that you don't need to remember which libraries you have to add to the final link command line. I understand that it is sometimes useful.

As I have implemented the feature to COFF lld, I know how it works and have learned a lot from it. From that perspective, I'd like to note that the feature is often too powerful and tricky. We don't want object files to change some basic behavior of the linker via an implicit way, but with that feature, you can do that. (Even if you wouldn't do that, someone who find the feature would become very "creative" and do something very tricky with it.) For example, do you want an object file to add the --relocatable option to the command line, or do you want to allow an object file to add more object files to be linked? I'd think the answer is no. Also, some command line options cannot be implemented correctly in the first place. For example, lld processes all linker scripts before linking any object files. If you try to add a linker script using --script=<filename>, it wouldn't work because it's too late to do that.

In addition to that, the feature would make the linker's behavior more unpredictable to the user because the final command line options depend on object files the linker would pull out of static archives. Imagine that two object files contain --as-needed and --no-as-needed. The final output would depend on what order these files are pulled out of the archive and linked.

Overall, I don't think we really want to allow *all* features, because it is extremely powerful and too easy to become out of control. I'd strongly prefer adding a limited set of features in a more controlled manner.


Repository:
  rL LLVM

https://reviews.llvm.org/D40849





More information about the llvm-commits mailing list