[PATCH] D67388: Add a feature to dump dependency graph.

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

I think that this will definitely be useful, especially to work out all the files that are involved in referencing a symbol. Looking to the future I'd recommend keeping the symbol dependency information, which is mostly useful for objects and libraries, from relocation dependencies as used in GC as the output is likely to be different and will answer different questions.  How do you want the final interface to look when there are many diagnostic analyses?

As I think I mentioned in the discussion on the mailing lists, the output of the final state of a data structure can lose information that is useful in tracking problems. A complementary technique is to optionally print information as we process, this can help to fix problems caused by ordering of libraries.



================
Comment at: lld/ELF/Driver.cpp:876
   config->pie = args.hasFlag(OPT_pie, OPT_no_pie, false);
+  config->printDependencyGraph = args.hasFlag(
+      OPT_print_dependency_graph, OPT_no_print_dependency_graph, false);
----------------
There are many types of dependency graph, for example the undefined symbol dependencies are not the same as GC/ICF dependencies. I think it would be worth being more specific, with the option name. There are also some options on future expansion:
- One flag for each dependency like option each with a different file name
- One flag for each dependency, but outputting to a single "map like" file
- An aggregated option like --dependency=<comma separated list> of topics. 


================
Comment at: lld/ELF/Driver.cpp:1680
+static void dumpSymbols() {
+  outs() << "# This is a dump of the internal symbol table of the lld linker\n"
+         << "# when linking '" << config->outputFile << "'.\n#\n"
----------------
This is more a slice of the internal symbol table. In particular it is the set of symbols defined by other objects. We may want to be precise about what we are printing, an object could define a weak symbol, but not refer to it, only to have it defined non-weakly in another file. This would show up as uses.  

```
For each object file participating in the linking of <object file>, print the Symbols that were defined by other object files.
The format of the file is:
# <file1> <file2> <symbol>
# meaning <file1> has <symbol> in its symbol table which was defined in <file2>.
```


================
Comment at: lld/ELF/Driver.cpp:1686
+
+  for (InputFile *file : objectFiles)
+    if (file->onCommandLine)
----------------
Personally I'd prefer not to include the files on the command line in this particular diagnostic. Although that information is useful I'd prefer to see it in a different diagnostic option to keep this one focused on symbol dependencies.

I can see myself writing a python/perl script to process this for large programs and whereas I could simply cut a static number of lines for the header, I'd have to account for the <commandline> in the parser. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67388