[PATCH] D136702: [llvm-cov] Look up object files using debuginfod

[Daniel Thornburgh via Phabricator via llvm-commits]

mysterymath added inline comments.


================
Comment at: compiler-rt/test/profile/lit.site.cfg.py.in:7
 config.target_arch = "@PROFILE_TEST_TARGET_ARCH@"
+config.have_curl = @LLVM_ENABLE_CURL@
 
----------------
phosek wrote:
> You need to pythonize this variable. For this to work with the runtimes build, we also need to export `LLVM_ENABLE_CURL` in `LLVMConfig.cmake`, see https://github.com/llvm/llvm-project/blob/7f48154ca11fee6579fe29a51ab2a329424d31c4/llvm/cmake/modules/LLVMConfig.cmake.in#L81
> 
> There's a broader question of whether we should be passing the variables like `LLVM_ENABLE_CURL` to the runtimes in the first build since they are only relevant to the LLVM build. A better approach would be to provide some indication whether debuginfod is available in the `llvm-cov --help` output (or perhaps have a dedicated flag) and then parse that information when running compiler-rt CMake build and use the result here.
> You need to pythonize this variable. For this to work with the runtimes build, we also need to export LLVM_ENABLE_CURL in LLVMConfig.cmake, see https://github.com/llvm/llvm-project/blob/7f48154ca11fee6579fe29a51ab2a329424d31c4/llvm/cmake/modules/LLVMConfig.cmake.in#L81
It looks like compiler-rt does this directly in cmake; I'll add this there for consistency.

> There's a broader question of whether we should be passing the variables like `LLVM_ENABLE_CURL` to the runtimes in the first build since they are only relevant to the LLVM build. A better approach would be to provide some indication whether debuginfod is available in the `llvm-cov --help` output (or perhaps have a dedicated flag) and then parse that information when running compiler-rt CMake build and use the result here.
Seems like the capabilities of the LLVM build are relevant to the compiler-rt tests, since they control the capabilities of the tools used in those tests. We could add optional capability advertisement generally to utilities, but I think one would probably want a principled way to do this; either something centralized like llvm-config, or a common flag to extract out optional capabilities in some format or another.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D136702