[PATCH] D130229: [ELF] Add --thinlto-index= and --remapping-file=

[Teresa Johnson via Phabricator via llvm-commits]

tejohnson added a comment.

I suppose the rationale for doing things this way is that you can keep the input files in the same ordering on the indexing link and the final native link, to avoid changing the relative order between files that were bitcode and files that were native already during the indexing link.

However, I'm a little confused as to how this will work for symbol resolution. The main reason for doing things the way we were was to ensure the same objects were selected for linking out of static libraries (that use --start-lib/--end-lib), since symbols may be referenced differently after importing. That's why the native objects corresponding to the bitcode files are listed in a flat list in the thinlto-index-only=params file (i.e. not using --start-lib/--end-lib). I'm not sure how the new solution prevents those issues.

E.g. If I change your example to use --start-lib/--end-lib:

  # ThinLTO indexing
  clang -flto=thin -fuse-ld=lld -Wl,--thinlto-index=out/exe.map -Wl,--thinlto-prefix-replace='out;lto' \
    -Wl,--thinlto-object-suffix-replace='.indexing.o;.o' out/a.o --start-lib out/b.indexing.o out/c.indexing.o --end-lib

Is the final link also like that?:

  # Final link
  clang -fuse-ld=lld -Wl,--remapping-file=out/exe.map out/a.o --start-lib out/b.indexing.o out/c.indexing.o --end-lib -o out/exe

I assume the symbol resolution is done on the post-mapping native objects, and not the bitcode objects, right? In more complex examples that could cause issues with which objects are selected, leading to similar problems as those this is trying to address relating to originally native objects.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130229