[PATCH] D96613: [lld] Add options to trace all symbols and to trace all symbols originated from a file

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

In D96613#2590895 <https://reviews.llvm.org/D96613#2590895>, @smeenai wrote:

> In D96613#2590870 <https://reviews.llvm.org/D96613#2590870>, @MaskRay wrote:
>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=27407
>> I think the functionality can be straightforwardly emulated. For example, `llvm-nm -Du` dumps undefined symbols in `.dynsym`.
>>
>> `% ld.lld @response.txt $(llvm-nm -Du usr/lib64/libc.so.6 | awk '{print "-y"substr($0,20)}')`
>>
>> This even works with versioned symbols while the patch doesn't. You can tweak `-u`: e.g. `-U` dumps defined symbols (`-U` is not in `nm`).
>> This is the flexibility provided by composing tools, which will be a bit inconvenient to implement in code.
>>
>> The patch uses `this->file`, however, the value may change if the symbol gets resolved to other files. In the cases I can conceive we want the trace of the full lifetime of a symbol, not only when it is bound to a specific file.
>
> In general, while there's a lot of value in being able to compose tools, I strongly disagree that it's an adequate replacement for having functionality directly built into a tool:

My opinion on this is still case by case. For the particular features, (1) the lack of customization of `-u`/-U` and (2) the `this->file` usage is my main concern about the new option.
(And a minor concern: `needToTraceSymbol` cost - that was why I re-stated that whether it would regress the symbol resolution performance)

> - You have to think about how to construct the appropriate pipeline, and in practice, you're going to have to re-remember how to construct that pipeline every single time you want to use it (vs. just remembering a simple command like `--trace-all-symbols`). (I know you can use aliases/shell functions/etc., but it's still a lot of overhead.)

New options have education costs. I've heard many internal reports where they want some build analysis features but they don't investigate(know) --cref/-Map/-y/etc.

> - If you want to integrate the functionality in your build system (e.g. you're trying to generate an aggregated report for all the libraries you build), a pipeline is much harder to integrate into your build system, vs. just adding an argument.
> - You have to worry about platform differences; e.g., lots of Linux utilities have different arguments or behaviors than their BSD (and therefore macOS) equivalents, and Windows doesn't have these utilities at all.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96613