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

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

In D115973#3228784 <https://reviews.llvm.org/D115973#3228784>, @MaskRay wrote:

> In 2021-01, https://lists.llvm.org/pipermail/llvm-dev/2021-January/148048.html (`[RFC] Cross-project lit test suite`) discussed some pain in cross-project debug info testing. Perhaps @jhenderson has some idea for the clang usage in the test.

I've not dug into this patch at all, but in general terms, the way I see it, you have about three options to craft DWARF in test objects these days:

1. yaml2obj with DWARF, if the support is sufficiently mature for your use-case, and the output is easy enough to read - one advantage with DWARF yaml2obj is that you can omit many of the required fields, unlike assembly, so depending on the complexity you need, this may be a better option for long-term maintenance.
2. Directly write assembly, and then use llvm-mc to compile it into the object file you want. If necessary, you might generate this assembly via clang, and then document the input source, the command line, the version of clang used to generate it, and any post-generation modifications you made. (Other variations might be to compile from IR or other similar input).
3. Add the test to cross-project-tests somewhere, and then use clang directly within the test (together with a `REQUIRES: clang` directive). However, this should really only be done if either of the above don't sensibly work OR you are testing the interaction between clang (explicitly clang, not the LLVM backend, for which you can use other tools like llc etc) and llvm-profdata.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115973