[PATCH] D115973: [llvm-profgen] Support symbol loading for debug fission

James Henderson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 15 00:14:02 PST 2022


jhenderson added a subscriber: Higuoxing.
jhenderson added a comment.

Pinging @Higuoxing, as he was the one who actually did a lot of the more recent yaml2obj DWARF implementation and may have some feedback on how best to reduce things.

Picking up on a couple of different points:

As @dblaikie mentioned, `cross-project-tests` is primarily for integration testing between LLVM components. One use case that is on the boundary line is llvm-symbolizer and other tool testing that need to consume a linked binary for their test case, as you can't use LLD outside of the `cross-project-tests` and the `lld` project. yaml2obj could be used for generating the test input objects in such cases, but as already noted, it may not be practical for some cases to reduce the YAML down to a usable document.

Regarding checked-in binaries as test inputs: I'd always prefer to avoid this, even if the only alternative is using an opaque assembly or YAML file as input, with instructions on how to generate it (specifically the input source, the compilation/linking commands, and the version of the tool(s) used in generating it). The reason for this is repository size: git isn't very good at keeping the size of committed binaries to a minimum, meaning that every binary ever checked into the repo, //even if not still in use// contributes to the size of people's local git repositories. It gets worse when that binary gets updated too. Another advantage with the checked-in source approach is that it's easy to get diffs between versions: say a tweak was made to the test input, it is usually fairly straightforward to see the differences that such a tweak cause from a diff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115973



More information about the llvm-commits mailing list