rocallahan added a comment. Sorry for not responding earlier. Phabricator insists on sending me emails about all issues in the system, and I never figured out how to get GMail to show me only emails about Phabricator issues I'm CCed on.
> I know little about Rust crates but I worry some component doesn't use static > archives .a correctly. If you don't have .a but you have a bunch of .o files, > you may place them inside a --start-lib ... --end-lib to get the archive > semantic. As I mentioned earlier, Rust already packs the object files for its "crates" (think libraries) into archives, so `--start-lib` ... `--end-lib` has no effect. The problem is that when the linker computes the transitive closure of dependencies at object file granularity, it finds that most object files in most Rust libraries are used. It's only when the linker computes the transitive closure of dependencies at function-sections granularity that it finds many functions are not used, and that in some object files all functions are unused. Is this still unclear? > recommend that people who want smaller debug info use tools like dsymutil, > dwz, DWP, or other format aware things that can remove unreferenced or > duplicate DWARF. A big advantage of pruning debuginfo in the linker instead of postprocessing the binaries is that the former makes the build faster (see https://reviews.llvm.org/D54747#1459175) and the latter makes the build slower. When a project statically links a lot of binaries (as large Rust projects tend to do for example) doubling the link I/O required is significant. (There might be a way to wire together the linker and a postprocessor via a tmpfs but it would be ugly and still suboptimal...) > I'm not sure how well that generalizes. On a local Clang build I performed, > for example, it made exactly 0 bytes difference. Perhaps the big wins only > happen in pathological cases that are better addressed some other way. You didn't say what kind of project you built locally, but I did expect this to have much less impact for C++ projects because their dependencies are often either a) dynamically linked b) manually vendored (in which case well-optimized projects only build the code they actually use) c) "single-header" libraries or d) manually assigning functions to TUs to optimize the link. As I mentioned earlier, Rust and C++ are significantly different here in that Rust does not require, or even allow, developers to manually assign functions to TUs. Combine that with Rust's preference for static linking and we have the problem I tried to address here. It might be possible to tackle this at the Rust level by assigning functions to TUs in a more intelligent way. That would never be as effective as having the linker strip unused data, because in the latter case the linker has full knowledge of what is used in the final binary, and in the former case the Rust compiler does not (and cannot, because the library may be used in different ways by different final binaries even in the same project). > So I think we should revert and rethink. Thanks for reverting and I'm sorry for causing those regressions. Even though it was rejected in https://reviews.llvm.org/D59553, I think the way forward would be to implement DWARF-level linking in LLD somehow. That would benefit C++ projects since you could shrink the generated DWARF with better overall performance than a postprocessor. It would also improve and simplify debuggers --- right now it's a real pain for debuggers to collect all relevant DWARF information for a given type from all the TUs clang can smear it over. DWARF-level linking is quite a big task so someone would probably need to pay someone to do it, and the LLD community would need to agree up front that it's acceptable, so time and money isn't wasted. Whatever you do, it will almost certainly need to be opt-in, since as noted in reason #1 in https://reviews.llvm.org/D54747#1505749 there are existing workflows that assume any debuginfo in a .o file on the link command line is preserved as-is. Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D54747/new/ https://reviews.llvm.org/D54747 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
