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

[hoy]

Summary

--trace-symbol=<symbol> only traces one symbol at a time, add :

• --trace-all-symbols to trace all symbols
• --trace-symbols-from-file=<file> to trace symbols referenced or defined in a file

[MaskRay]

I created https://sourceware.org/bugzilla/show_bug.cgi?id=27407 asking for binutils opinions.

lld/ELF/Symbols.h

535

Can you measure how much slowdown this will cause?

[hoy]

In D96613#2560322, @MaskRay wrote:

I created https://sourceware.org/bugzilla/show_bug.cgi?id=27407 asking for binutils opinions.

Thanks for gather's inputs from binutils. I'm curious about how they view this.

Regarding the throughput impact, I was seeing --trace-all-symbols slowed down the linker by 2x for a final executable around 60M unfortunately. Since it is a debug switch, I would imagine people whoever use this would be willing to pay for its cost.

[hoy]

Fixing lint issue.

[hoy]

@MaskRay I'm wondering if you've got any update from the binutils side. Thanks.

[MaskRay]

In D96613#2579750, @hoy wrote:

@MaskRay I'm wondering if you've got any update from the binutils side. Thanks.

I even pinged that for you: https://sourceware.org/pipermail/binutils/2021-February/115455.html
If you want to reply, you can download https://sourceware.org/pipermail/binutils/2021-February.txt.gz , extract the Message-ID as your In-Reply-To: header.

[MaskRay]

lld/ELF/Symbols.h

535

And ping on this question: the condition is pretty complex. Does it affect symbol resolution time?

[hoy]

In D96613#2579911, @MaskRay wrote:

In D96613#2579750, @hoy wrote:

@MaskRay I'm wondering if you've got any update from the binutils side. Thanks.

I even pinged that for you: https://sourceware.org/pipermail/binutils/2021-February/115455.html
If you want to reply, you can download https://sourceware.org/pipermail/binutils/2021-February.txt.gz , extract the Message-ID as your In-Reply-To: header.

Thanks for pinging for me!

lld/ELF/Symbols.h

535

Sorry, I misunderstood your question. I haven't seen noticeable link time difference w/ and w/o this function when no tracing switches is turned on.

[MaskRay]

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.

[smeenai]

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

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

[MaskRay]

In D96613#2590895, @smeenai wrote:

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

I think a small set of composable options for build dependency analysis will be useful, but we need to consolidate the requests and think of their composability/maintenance/etc. Apologies but I feel that "Linux utilities have different arguments or behaviors than their BSD" in this particular context is probably a weak argument: here we use LLVM binary utilities and a common 'awk' (which can be reimplemented in build system language straightforwardly). Many downstream groups have bundled LLVM binary utilities as platform-neutral utilities which are already used heavily in build systems. We don't necessarily re-invent features provided by them in LLD.

[smeenai]

In D96613#2590948, @MaskRay wrote:

In D96613#2590895, @smeenai wrote:

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

[MaskRay]

I edited my previous comment to include a bit more information.

For discoverability, if people know that --trace-symbol, re-inventing this mechanism is simple. nm (llvm-nm) is well-known utility to dump the symbol table. Composing nm and ld.lld together is straightforward.

[smeenai]

In D96613#2590948, @MaskRay wrote:

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

I think a small set of composable options for build dependency analysis will be useful, but we need to consolidate the requests and think of their composability/maintenance/etc. Apologies but I feel that "Linux utilities have different arguments or behaviors than their BSD" in this particular context is probably a weak argument: here we use LLVM binary utilities and a common 'awk' (which can be reimplemented in build system language straightforwardly). Many downstream groups have bundled LLVM binary utilities as platform-neutral utilities which are already used heavily in build systems. We don't necessarily re-invent features provided by them in LLD.

In D96613#2590976, @MaskRay wrote:

For discoverability, if people know that --trace-symbol, re-inventing this mechanism is simple. nm (llvm-nm) is well-known utility to dump the symbol table. Composing nm and ld.lld together is straightforward.

I agree that we should be thinking about the composability and maintenance burden of new options, and thinking about this in a holistic way (and not just always adding one-off options for each request). At the same time, I disagree with your assessment of how straightforward it is to compose different tools together. Fair point about the awk functionality in your command being the same across Unixes, but awk still isn't a thing on Windows, and whether it's straightforward or not to reimplement the equivalent functionality in your build system language depends on your build system. Furthermore, I think text processing is inherently fragile in general; it's fair to assume that a tool like llvm-nm isn't going to be changing its output format, but you still have to put a lot more thought into setting up an appropriate pipeline than you would into using a built-in option.

Case in point: you're using the following invocation:

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

I don't know why this is, but both GNU nm and llvm-nm print a different number of leading spaces for 32 vs. 64-bit binaries. If I do llvm-nm -Du /usr/lib/libc.so.6 (instead of /usr/lib64/libc.so.6), I need to change the substr amount to 12 instead of 20. I could use $2 (as in the second field) instead, but that'll break if my symbol name has spaces in it (which definitely occurs for Objective-C, at least). (Incidentally, you're not putting quotes around your -y command, so it'll also break if the symbol name has spaces in it, which is one of the generally fragile things about shell pipelines.) Fortunately, llvm-nm has a --just-symbol-name option (which at least my version of GNU nm doesn't), which'll work regardless of the output format for the particular architecture, and handle symbol names with spaces without any issues. There's clear value to having the --just-symbol-name flag IMO, even though you could theoretically emulate the same functionality with a shell pipeline, since it lets you not have to worry about all these caveats.

[hoy]

@MaskRay I think your concern is primarily about the extra condition checks in Symbol::needToTraceSymbol that may slow down the linker. Is there a linker performance testing system on your side that you can help evaluate it? I have manually run the patch against medium-sized programs and haven't seen regressions. Otherwise, I agree with @smeenai that we should be open to changes that make life easier with little cost.

[MaskRay]

I have several concerns.

• The slowdown. You can test some internal projects.
• This does not work with versioned symbols in shared objects.
• 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.
• The usefulness is not justified. This looks like a debug option. I raised ld.lld @response.txt $(llvm-nm -Du usr/lib64/libc.so.6 | awk '{print "-y"substr($0,20)}') as an example how this can be trivially implemented with tool composing.

https://sourceware.org/bugzilla/show_bug.cgi?id=27407 If you can make arguments there, it will probably make this proposal more competitive.

[hoy]

In D96613#2592675, @MaskRay wrote:

I have several concerns.

• The slowdown. You can test some internal projects.

Our internal projects mostly use thinLTO thus the overhead here is negligible. Without thinLTO, generated code becomes much smaller (due to lack of cross-module inlining). Anyway, I'll continue my measurement. If there's any regression, I think we can optimize the checks to just favor non-debug scenario, like another bool flag to identify if config->traceSymbolsFromFile is empty?

• This does not work with versioned symbols in shared objects.

Does the exiting --trace-symbol handle versioned symbols?

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

Is this for weak symbols? --trace-symbols-from-file aims to trace where a definition of a symbol is finally picked up.

• The usefulness is not justified. This looks like a debug option. I raised ld.lld @response.txt $(llvm-nm -Du usr/lib64/libc.so.6 | awk '{print "-y"substr($0,20)}') as an example how this can be trivially implemented with tool composing.

As @smeenai pointed out, that approach also has limitations.

https://sourceware.org/bugzilla/show_bug.cgi?id=27407 If you can make arguments there, it will probably make this proposal more competitive.

Sorry, I don't quite get this. Are we trying to have the gnu linker implement the two switches as well? I don't see an objection on their side.

[MaskRay]

In D96613#2593029, @hoy wrote:

In D96613#2592675, @MaskRay wrote:

I have several concerns.

• The slowdown. You can test some internal projects.

Our internal projects mostly use thinLTO thus the overhead here is negligible. Without thinLTO, generated code becomes much smaller (due to lack of cross-module inlining). Anyway, I'll continue my measurement. If there's any regression, I think we can optimize the checks to just favor non-debug scenario, like another bool flag to identify if config->traceSymbolsFromFile is empty?

• This does not work with versioned symbols in shared objects.

Does the exiting --trace-symbol handle versioned symbols?

Yes. See verneed-shared.s

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

Is this for weak symbols? --trace-symbols-from-file aims to trace where a definition of a symbol is finally picked up.

Not just weak symbols. See resolveUndefined where an undefined symbol's file can be replaced.
By using Symbol::file, the semantics of the patch are not clear.

• The usefulness is not justified. This looks like a debug option. I raised ld.lld @response.txt $(llvm-nm -Du usr/lib64/libc.so.6 | awk '{print "-y"substr($0,20)}') as an example how this can be trivially implemented with tool composing.

As @smeenai pointed out, that approach also has limitations.

You are proposing new options, so you need to justify the options. I've also asked other folks and many feel that this is unnecessary.
I forgot llvm-nm --just-symbol-name. How is this proposal more competitive than composing llvm-nm --just-symbol-name and ld.lld?

https://sourceware.org/bugzilla/show_bug.cgi?id=27407 If you can make arguments there, it will probably make this proposal more competitive.

Sorry, I don't quite get this. Are we trying to have the gnu linker implement the two switches as well? I don't see an objection on their side.

When things are in doubts, one tie-breaking thing you can try is to make other implementations accept your proposal. That could justify the merit of the proposal.

lld/ELF/Config.h

 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/StringSet.h"
 #include "llvm/BinaryFormat/ELF.h"
 #include "llvm/Support/CachePruning.h"
 #include "llvm/Support/CodeGen.h"
 #include "llvm/Support/Endian.h"
 #include "llvm/Support/GlobPattern.h"
 #include <atomic>
+#include <unordered_set>
 #include <vector>
 
 namespace lld {
 namespace elf {
 
 class InputFile;
 class InputSectionBase;
 
struct Configuration {
   llvm::StringRef soName;
   llvm::StringRef sysroot;
   llvm::StringRef thinLTOCacheDir;
   llvm::StringRef thinLTOIndexOnlyArg;
   llvm::StringRef ltoBasicBlockSections;
   std::pair<llvm::StringRef, llvm::StringRef> thinLTOObjectSuffixReplace;
   std::pair<llvm::StringRef, llvm::StringRef> thinLTOPrefixReplace;
   std::string rpath;
+  std::unordered_set<llvm::StringRef> traceSymbolsFromFile;
   std::vector<VersionDefinition> versionDefinitions;
   std::vector<llvm::StringRef> auxiliaryList;
   std::vector<llvm::StringRef> filterList;
   std::vector<llvm::StringRef> searchPaths;
   std::vector<llvm::StringRef> symbolOrderingFile;
   std::vector<llvm::StringRef> thinLTOModulesToCompile;
   std::vector<llvm::StringRef> undefined;
   std::vector<SymbolVersion> dynamicList;
struct Configuration {
   llvm::Optional<uint32_t> shuffleSectionSeed;
   bool singleRoRx;
   bool shared;
   bool symbolic;
   bool isStatic = false;
   bool sysvHash = false;
   bool target1Rel;
   bool trace;
+  bool traceAllSymbols;
   bool thinLTOEmitImportsFiles;
   bool thinLTOIndexOnly;
   bool timeTraceEnabled;
   bool tocOptimize;
   bool pcRelOptimize;
   bool undefinedVersion;
   bool unique;
   bool useAndroidRelrTags = false;

lld/ELF/Driver.cpp

static std::pair<bool, bool> getPackDynRelocs(opt::InputArgList &args) {
   if (s == "android+relr")
     return {true, true};
 
   if (s != "none")
     error("unknown -pack-dyn-relocs format: " + s);
   return {false, false};
 }
 
+static std::unordered_set<llvm::StringRef>
+getTraceSymbolsFromFile(opt::InputArgList &Args) {
+  std::vector<llvm::StringRef> v =
+      args::getStrings(Args, OPT_trace_symbols_from_file);
+  std::unordered_set<llvm::StringRef> traceSymbolsFromFile(
+      std::make_move_iterator(v.begin()), std::make_move_iterator(v.end()));
+  return traceSymbolsFromFile;
+}
+
 static void readCallGraph(MemoryBufferRef mb) {
   // Build a map from symbol name to section
   DenseMap<StringRef, Symbol *> map;
   for (InputFile *file : objectFiles)
     for (Symbol *sym : file->getSymbols())
       map[sym->getName()] = sym;
 
   auto findSection = [&](StringRef name) -> InputSectionBase * {
static void readConfigs(opt::InputArgList &args) {
   config->thinLTOPrefixReplace =
       getOldNewOptions(args, OPT_thinlto_prefix_replace_eq);
   config->thinLTOModulesToCompile =
       args::getStrings(args, OPT_thinlto_single_module_eq);
   config->timeTraceEnabled = args.hasArg(OPT_time_trace);
   config->timeTraceGranularity =
       args::getInteger(args, OPT_time_trace_granularity, 500);
   config->trace = args.hasArg(OPT_trace);
+  config->traceAllSymbols = args.hasArg(OPT_trace_all_symbols);
+  config->traceSymbolsFromFile = getTraceSymbolsFromFile(args);
   config->undefined = args::getStrings(args, OPT_undefined);
   config->undefinedVersion =
       args.hasFlag(OPT_undefined_version, OPT_no_undefined_version, true);
   config->unique = args.hasArg(OPT_unique);
   config->useAndroidRelrTags = args.hasFlag(
       OPT_use_android_relr_tags, OPT_no_use_android_relr_tags, false);
   config->warnBackrefs =
       args.hasFlag(OPT_warn_backrefs, OPT_no_warn_backrefs, false);

lld/ELF/Options.td

defm toc_optimize : BB<"toc-optimize",
     "(PowerPC64) Disable TOC related optimizations">;
 
 defm pcrel_optimize : BB<"pcrel-optimize",
     "(PowerPC64) Enable PC-relative optimizations (default)",
     "(PowerPC64) Disable PC-relative optimizations">;
 
 def trace: F<"trace">, HelpText<"Print the names of the input files">;
 
+def trace_all_symbols: F<"trace-all-symbols">, HelpText<"Trace references to all symbols">;
+
+defm trace_symbols_from_file: Eq<"trace-symbols-from-file",
+     "Trace symbols referenced or defined in a file">;
+
 defm trace_symbol: Eq<"trace-symbol", "Trace references to symbols">;
 
 defm undefined: Eq<"undefined", "Force undefined symbol during linking">,
   MetaVarName<"<symbol>">;
 
 defm undefined_glob: EEq<"undefined-glob", "Force undefined symbol during linking">,
   MetaVarName<"<pattern>">;
 

lld/ELF/Symbols.h

public:
   // if the first undefined reference from a non-shared object is weak.
   //
   // This is also used to retain __wrap_foo when foo is referenced.
   uint8_t referenced : 1;
 
   // True if this symbol is specified by --trace-symbol option.
   uint8_t traced : 1;
 
+  inline bool needToTraceSymbol();
   inline void replace(const Symbol &newSym);
 
   bool includeInDynsym() const;
   uint8_t computeBinding() const;
   bool isWeak() const { return binding == llvm::ELF::STB_WEAK; }
 
   bool isUndefined() const { return symbolKind == UndefinedKind; }
   bool isCommon() const { return symbolKind == CommonKind; }
size_t Symbol::getSymbolSize() const {
   case UndefinedKind:
     return sizeof(Undefined);
   case PlaceholderKind:
     return sizeof(Symbol);
   }
   llvm_unreachable("unknown symbol kind");
 }
 
+// The symbol table is initialized after the file is parsed, but
+// symbol tracing information is printed during parsing.  If we
+// want to print tracing information of symbols in a file, we need
+// to check that the symbol is in the file the first time it is
+// processed.
+bool Symbol::needToTraceSymbol() {
+  return traced || config->traceAllSymbols ||
+         (this->file != nullptr &&
+          config->traceSymbolsFromFile.find(this->file->getName()) !=
+              config->traceSymbolsFromFile.end());
+}
+
 // replace() replaces "this" object with a given symbol by memcpy'ing
 // it over to "this". This function is called as a result of name
 // resolution, e.g. to replace an undefind symbol with a defined symbol.
 void Symbol::replace(const Symbol &newSym) {
   using llvm::ELF::STT_TLS;
 
   // st_value of STT_TLS represents the assigned offset, not the actual address
   // which is used by STT_FUNC and STT_OBJECT. STT_TLS symbols can only be
void Symbol::replace(const Symbol &newSym) {
   scriptDefined = old.scriptDefined;
   partition = old.partition;
 
   // Symbol length is computed lazily. If we already know a symbol length,
   // propagate it.
   if (nameData == old.nameData && nameSize == 0 && old.nameSize != 0)
     nameSize = old.nameSize;
 
-  // Print out a log message if --trace-symbol was specified.
+  // Print out a log message if --trace-symbol or --trace-all-symbols
+  // was specified.
   // This is for debugging.
-  if (traced)
+  if (needToTraceSymbol())
     printTraceSymbol(this);
 }
 
 void maybeWarnUnorderableSymbol(const Symbol *sym);
 bool computeIsPreemptible(const Symbol &sym);
 void reportBackrefs();
 
 // A mapping from a symbol to an InputFile referencing it backward. Used by

lld/ELF/Symbols.cpp

void Symbol::resolveUndefined(const Undefined &other) {
   // If this is a non-weak defined symbol in a discarded section, override the
   // existing undefined symbol for better error message later.
   if ((isShared() && other.visibility != STV_DEFAULT) ||
       (isUndefined() && other.binding != STB_WEAK && other.discardedSecIdx)) {
     replace(other);
     return;
   }
 
-  if (traced)
+  if (needToTraceSymbol())
     printTraceSymbol(&other);
 
   if (isLazy()) {
     // An undefined weak will not fetch archive members. See comment on Lazy in
     // Symbols.h for the details.
     if (other.binding == STB_WEAK) {
       binding = STB_WEAK;
       type = other.type;

lld/test/ELF/trace-all-symbols.s

+# REQUIRES: x86
+# Test --trace-all-symbols
+
+# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t
+# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux \
+# RUN: %p/Inputs/trace-symbols-foo-weak.s -o %t1
+# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux \
+# RUN: %p/Inputs/trace-symbols-foo-strong.s -o %t2
+# RUN: ld.lld -shared %t1 -o %t1.so
+# RUN: ld.lld -shared %t2 -o %t2.so
+# RUN: rm -f %t1.a
+# RUN: llvm-ar rcs %t1.a %t1
+# RUN: rm -f %t2.a
+# RUN: llvm-ar rcs %t2.a %t2
+
+# RUN: ld.lld --trace-all-symbols %t %t1 %t2 -o %t3 | FileCheck %s
+# CHECK-DAG: trace-all-symbols.s.tmp: definition of _start
+# CHECK-DAG: trace-all-symbols.s.tmp: reference to foo
+# CHECK-DAG: trace-all-symbols.s.tmp1: reference to bar
+# CHECK-DAG: trace-all-symbols.s.tmp1: common definition of common
+# CHECK-DAG: trace-all-symbols.s.tmp1: definition of foo
+# CHECK-DAG: trace-all-symbols.s.tmp1: definition of func1
+# CHECK-DAG: trace-all-symbols.s.tmp1: reference to func2
+# CHECK-DAG: trace-all-symbols.s.tmp2: definition of bar
+# CHECK-DAG: trace-all-symbols.s.tmp2: definition of foo
+# CHECK-DAG: trace-all-symbols.s.tmp2: definition of func2
+# CHECK-DAG: trace-all-symbols.s.tmp1: definition of common
+
+.hidden hsymbol
+.globl  _start
+.type _start, @function
+_start:
+call foo

lld/test/ELF/trace-file.s

+# REQUIRES: x86
+# Test --trace-symbols-from-file=file and --trace-symbol=symbol
+
+# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t
+# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux \
+# RUN: %p/Inputs/trace-symbols-foo-weak.s -o %t1
+# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux \
+# RUN: %p/Inputs/trace-symbols-foo-strong.s -o %t2
+# RUN: ld.lld -shared %t1 -o %t1.so
+# RUN: ld.lld -shared %t2 -o %t2.so
+# RUN: rm -f %t1.a
+# RUN: llvm-ar rcs %t1.a %t1
+# RUN: rm -f %t2.a
+# RUN: llvm-ar rcs %t2.a %t2
+
+# RUN: ld.lld --trace-symbols-from-file=%t %t %t1 %t2 -o %t3 | FileCheck --check-prefix=FILE0 %s
+# FILE0-DAG: trace-file.s.tmp: definition of _start
+# FILE0-DAG: trace-file.s.tmp: reference to foo
+
+# RUN: ld.lld --trace-symbols-from-file=%t1 %t %t1 %t2 -o %t3 | FileCheck --check-prefix=FILE1 %s
+# FILE1-DAG: trace-file.s.tmp1: reference to bar
+# FILE1-DAG: trace-file.s.tmp1: common definition of common
+# FILE1-DAG: trace-file.s.tmp1: definition of foo
+# FILE1-DAG: trace-file.s.tmp1: definition of func1
+# FILE1-DAG: trace-file.s.tmp1: reference to func2
+# FILE1-DAG: trace-file.s.tmp1: definition of common
+
+# RUN: ld.lld --trace-symbols-from-file=%t --trace-symbols-from-file=%t1 %t %t1 %t2 -o %t3 | FileCheck --check-prefix=FILE0AND1 %s
+# FILE0AND1-DAG: trace-file.s.tmp: definition of _start
+# FILE0AND1-DAG: trace-file.s.tmp: reference to foo
+# FILE0AND1-DAG: trace-file.s.tmp1: reference to bar
+# FILE0AND1-DAG: trace-file.s.tmp1: common definition of common
+# FILE0AND1-DAG: trace-file.s.tmp1: definition of foo
+# FILE0AND1-DAG: trace-file.s.tmp1: definition of func1
+# FILE0AND1-DAG: trace-file.s.tmp1: reference to func2
+# FILE0AND1-DAG: trace-file.s.tmp1: definition of common
+
+# RUN: ld.lld --trace-symbols-from-file=%t --trace-symbol=foo %t %t1 %t2 -o %t3 | FileCheck --check-prefix=FILE0FOO %s
+# FILE0FOO-DAG: trace-file.s.tmp: definition of _start
+# FILE0FOO-DAG: trace-file.s.tmp: reference to foo
+# FILE0FOO-DAG: trace-file.s.tmp1: definition of foo
+# FILE0FOO-DAG: trace-file.s.tmp2: definition of foo
+
+.hidden hsymbol
+.globl  _start
+.type _start, @function
+_start:
+call foo