[PATCH] D117284: [ELF] Allow non-bitcode archive with an empty index

Fri Jan 14 10:43:34 PST 2022

MaskRay added a comment.

In D117284#3243073 <https://reviews.llvm.org/D117284#3243073>, @peter.smith wrote:

> I can see that something like this could be valuable for a program using archives for major subsystems, although less well for a set of loosely connected utility routines (C-library). Doing this transparently makes me a little bit nervous for the reasons you suggest in the description.

Thanks for the comments. For the less well part, if the user cares about GNU ld compatibility, I think it's pretty straightforward to detect the problem (GNU ld does not link) and fix it by running ranlib.

> A couple of alternative suggestions:
>
> Could introduce something like --start-lib --end-lib to treat archives in this way (regardless of whether they have an index or not. Something like --start-as-lazy archive1.a archive2.a --end-as-lazy. That would permit people to get the potential speed boost while being under control, their archives (with indexes) will still work on linkers that don't support the option.
>
> Another option would be to enable the behaviour change via the command-line. At least people would then know that they would be doing something speciall 
> `--archive-no-index-as-lazy=<archive type>` where <archive type> is one of:
>
> - none. All archives without an index get an error message.
> - bitcode. All bitcode archives without an index are treated as a lazy archive. This is the default.
> - all. All archives without an index are treated as a lazy archive.

I imagine that we will introduce an option to treat all archives as a group of lazy files, maybe --archive-handling=<type> where <type> is one of:

- default: with index: traditional behavior, without index: a group of lazy object files
- lazy: a group of lazy object files ignoring the index

An option specifically for archives without an index seems to do too much.

I think it is good for ld.lld to influence the ecosystem in good directions. Normally we tend to be strict. For this archive case, if the traditional index constraint may not be useful and isn't difficult to repair (ranlib), I think losing some strictness is fine.
The patch also improves consistency. ET_REL files should not be handled differently than LLVM bitcode files.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D117284/new/

https://reviews.llvm.org/D117284