Bug 27407 - Add --trace-symbols-from-file?
Summary: Add --trace-symbols-from-file?
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2021-02-12 17:36 UTC by Fangrui Song
Modified: 2021-03-01 13:06 UTC (History)
1 user (show)

See Also:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Fangrui Song 2021-02-12 17:36:10 UTC
I noticed that someone wants to add --trace-all-symbols & --trace-symbols-from-file=<file> to ld.lld . They are variants that

* trace all symbols
* trace all symbols referenced or defined in a file

I think --trace-symbols-from-file= is mildly useful. It can used to tell why an archive member is extracted. --trace-all-symbols can arguably be replaced with --trace-symbols-from-file=* so is not necessary.
Comment 1 Nick Clifton 2021-02-26 14:42:34 UTC
Hi Fangrui,

   Does lld support the @<file> command line option ?

  ld.bfd supports this and it allows a user to place as many command line options as they like into <file>.  So this is a more general solution to the problem and would work for options other than --trace-symbol as well.

Comment 2 Fangrui Song 2021-02-26 19:47:18 UTC
Yes, response files are accepted by many llvm-project tools. You reminded me that we can compose tools, e.g.

ld.bfd @response.txt $(nm -Du usr/lib64/libc.so.6 | awk '{print "-y"substr($0,20)}')

For object files, -D probably should be changed to -g.
There is some flexibility composing can provide: nm -u can be changed to --defined-only to trace only defined symbols.

So it is unnecessary for ld to support such file tracing features.
Comment 3 Nick Clifton 2021-03-01 13:06:18 UTC
OK, closing