[PATCH] D133740: [ELF][Distributed ThinLTO] Do not generate empty index when bitcode object is linked
Christy Lee via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Tue Sep 13 12:19:10 PDT 2022
christylee added a comment.
In D133740#3787303 <https://reviews.llvm.org/D133740#3787303>, @MaskRay wrote:
> In D133740#3786811 <https://reviews.llvm.org/D133740#3786811>, @weiwang wrote:
>
>> In D133740#3785549 <https://reviews.llvm.org/D133740#3785549>, @MaskRay wrote:
>>
>>> For Bazel like build systems, it seems weird to have one object file in two modes, lazy and non-lazy. Do you know why it happens for your build system?
>>> I think the change will improve robustness of lld's distributed ThinLTO usage so we probably need to make the change.
>>
>> We've seen the case of 2 same lazy objects in buck, and the cause for that is still a mystery to us. @christylee may know more.
>
> Such a build system usually deduplicates linker input. I have seen duplicate archives but they are -lc, -lc++, etc, not from `cc_library` like targets.
> Technically with linker scripts `INPUT` and `GROUP` an archive can be referenced by two `cc_library`, but that's a very rare case usually implying a user mistake but I feel the linker can guard against it, which will also help traditional build systems which don't do a great job deduplicating input.
We've seen two cases:
1. Older rust compilers will duplicate transitive dependencies, including C++ dependencies.
2. Third-party prebuilt libraries that are wrapped with `--start-group/--end-group` and can be referenced by multiple `cc_library`. This is technically a user error but it's very hard to debug.
>> I listed the case of lazy and non-lazy just for the sake of test coverage.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D133740/new/
https://reviews.llvm.org/D133740
More information about the llvm-commits
mailing list