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

[Shoaib Meenai via Phabricator via llvm-commits]

smeenai added a comment.

In D96613#2590948 <https://reviews.llvm.org/D96613#2590948>, @MaskRay wrote:

> 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)

Yup, we should still be evaluating new options on their merits and drawbacks, of course. I just meant that we shouldn't be preventing some functionality from being built directly into a tool just because you can also emulate the same results by composing other tools.

>> - 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.

Agreed, but I also think they're more discoverable (e.g. by reading the `--help` output or man pages).

>> - 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