This is an archive of the discontinued LLVM Phabricator instance.

[llvm-cov] Look up object files using debuginfod
ClosedPublic

Authored by mysterymath on Oct 25 2022, 10:58 AM.

Diff Detail

Event Timeline

mysterymath created this revision.Oct 25 2022, 10:58 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 25 2022, 10:58 AM
Herald added a subscriber: hiraditya. · View Herald Transcript

Remove error condition when no files specified.

Allow mixing object files and fetched build IDs.

Extract the build IDs from the given files.

Fix logic and add tests and documentation.

mysterymath published this revision for review.Nov 4 2022, 4:07 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptNov 4 2022, 4:07 PM
Herald added subscribers: llvm-commits, Restricted Project. · View Herald Transcript

Clean the patch a bit.

Couple of drive-by comments, as my Herald rule triggered due to the llvm-objdump/llvm-symbolizer changes (which look fine to me).

llvm/lib/Debuginfod/Debuginfod.cpp
61 ↗(On Diff #473365)

In other parts of the codebase, consumeError without any explanation is generally a code smell. A comment explaining why it's appropriate instead of returning the error up the stack would be worthwhile here.

llvm/tools/llvm-cov/CodeCoverage.cpp
661

There seems to be an unfortunate mixture of help descriptions ending with full stops and others that don't. It seems no full stop in this file is more prevalent, so please remove it.

mysterymath marked an inline comment as done.

Address review comments.
Refactor getDefaultDebuginfodUrls.

llvm/lib/Debuginfod/Debuginfod.cpp
61 ↗(On Diff #473365)

Several of the debuginfod functions return Expected even though they have no possibility of failure, which seems like the root of the smell. I've refactored this call to just return a value.

Thanks for the minor changes. I'll leave reviewing the rest of this to someone else with more applicable knowledge.

llvm/lib/Debuginfod/Debuginfod.cpp
61 ↗(On Diff #473365)

Cool, looks good.

ellis added inline comments.Nov 11 2022, 11:13 AM
llvm/docs/CommandGuide/llvm-cov.rst
352 ↗(On Diff #474618)

Can we add a test that uses this option? Maybe a test to make sure we can disable it without problem.

llvm/tools/llvm-cov/CodeCoverage.cpp
660

I personally prefer cl::ZeroOrMore rather than cl::Optional because I believe cl::Optional will fail if this option occurs twice. Does that make sense for these options?

mysterymath marked an inline comment as done.

Addressed review comments.

Testing this patch using file:// URLs uncovered an minor issue in the
Debuginfod client. Fixed this, allowing file URLs to work.

mysterymath added inline comments.Nov 11 2022, 3:57 PM
llvm/tools/llvm-cov/CodeCoverage.cpp
660

SGTM; I'm generally a fan of the the last-flag-wins semantics as well.

Integrate previous patch.
Require curl for debuginfod test.

Fix have_curl configuration in compiler-rt lit site config.

gulfem added inline comments.Jan 13 2023, 4:06 PM
compiler-rt/test/profile/Linux/binary-id-debuginfod.c
13 ↗(On Diff #482976)

Should this be -debuginfod instead of -debuginfod=0? Are you trying to enable debuginfod option here?

compiler-rt/test/profile/Linux/binary-id-lookup.c
14 ↗(On Diff #482976)

Can you extend both tests to check the line and coverage numbers instead of just checking the function names?

llvm/docs/CommandGuide/llvm-cov.rst
356 ↗(On Diff #482976)

Maybe "but its object file is not provided on the command line"?

llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
447

What happens when -debug-file-directory option is provided and there is no debug file that includes coverage data? For example, what happens if an empty directory or a directory with uninstrumented binaries is provided? When the object file that is provided does not contain any coverage instrumentation, this line should catch that it is a no_data_found error. With the new changes, I think this line would not be an error because ObjectFilenames will be empty if we only provide -debug-file-directory. So, I think it won't be able report any coverage, but it won't report an error. That's why I suggest adding a test with empty directory and check the expected behavior?

llvm/tools/llvm-cov/CodeCoverage.cpp
771

Should we only create a BIDFetcher when -debuginfod or -debug-file-directory options are provided? This seems to create a BIDFetcher by default even if those options are not provided.

Can you remove the dot at the end of the commit message? ([llvm-cov] Look up object files using debuginfod.)

mysterymath marked 2 inline comments as done.

Address review comments.

Can you remove the dot at the end of the commit message? ([llvm-cov] Look up object files using debuginfod.

Done.

compiler-rt/test/profile/Linux/binary-id-debuginfod.c
13 ↗(On Diff #482976)

Changed this to -debuginfod=false and renamed the CHECK to NODEBUGINFOD to clarify. debuginfod should default on when compiled with curl and if DEBUGINFOD_URLS is specified.

llvm/docs/CommandGuide/llvm-cov.rst
356 ↗(On Diff #482976)

Tightened up the wording here along those lines. Done.

llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
447

I was originally worried about changing the behavior of this line WRT when ObjectFilenames were empty, but looking at the broader codebase, it doesn't look like the empty ObjectFilename case was ever possible. An early exit occured on empty ObjectFilenames before this line on every path that called CoverageMapping::load.

Accordingly, I've just changed this to emit an error if no data was found. I've also added a check for this error.

llvm/tools/llvm-cov/CodeCoverage.cpp
771

That's intentional, to parallel how the other utilities in llvm work. There are system default directories provided by Linux distributions that contain DWARF object files whenever debug packages are installed; these directories are implicitly present in the -debug-file-directory list, and the default BIDFetcher will pick these up.

mysterymath retitled this revision from [llvm-cov] Look up object files using debuginfod. to [llvm-cov] Look up object files using debuginfod.Jan 23 2023, 4:55 PM

Correct description of -debug-file-directory.

gulfem accepted this revision.Jan 24 2023, 5:27 PM
This revision is now accepted and ready to land.Jan 24 2023, 5:27 PM
This revision was landed with ongoing or failed builds.Jan 25 2023, 2:00 PM
This revision was automatically updated to reflect the committed changes.
dyung added a comment.Jan 25 2023, 7:25 PM

@mysterymath I reverted this change as well as follow-up change you made in order to unblock the build bots.

phosek added a subscriber: phosek.Jan 25 2023, 11:46 PM
phosek added inline comments.
compiler-rt/test/profile/lit.site.cfg.py.in
7 ↗(On Diff #492252)

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.

@mysterymath I reverted this change as well as follow-up change you made in order to unblock the build bots.

Thanks, sorry about that.

mysterymath added inline comments.Jan 26 2023, 1:00 PM
compiler-rt/test/profile/lit.site.cfg.py.in
7 ↗(On Diff #492252)

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.

jgorbe added a subscriber: jgorbe.Jan 27 2023, 10:29 AM
jgorbe added inline comments.
llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
422

We're getting build errors here (and the similar call to std::unique on line 426) with -Wunused-result.

This looks like a bug: std::unique returns the new end of the range, and typically you need to call container.erase(new_end, container.end()) after the call to std::unique to reduce the container size to match the new logical size. See https://en.cppreference.com/w/cpp/algorithm/unique.

mysterymath added inline comments.Jan 27 2023, 12:26 PM
llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
422

Thanks; did a quick fix forward for this. This uncovered a mistake with Compare as well; std::unique requires a == comparator, while sort and set_difference a < comparator.

dblaikie added inline comments.
llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
422

Is there test coverage for these bugs/fixes?

mysterymath added inline comments.Jan 30 2023, 10:44 AM
llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
422

Partially; the unused result lint caught the issue with std::unique; fixing that caused the original test cases to fail due to the comparator issue.

dblaikie added inline comments.Jan 30 2023, 11:23 AM
llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
422

Could you see about adding a test case that would've failed with the code as originally committed? (something that demonstrates the need for the unique call in the first place)

mysterymath added inline comments.Jan 30 2023, 1:39 PM
llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
422

I took a closer look at the gulfem's preceding change (https://reviews.llvm.org/D135929), and it appears that the std::unique here is superfluous; there's no effective way to produce duplicate build IDs in ProfileBinaryIDs, and in that case, they're harmless in FoundBinaryIDs, since std::max(1-k, 0) is 0 for any k >= 1. The ProfileBinaryIDs sort is also superfluous.

That does mean there's intrinsically no way to test it, since it makes no observable difference. I've thus removed the uniquing logic completely.

dblaikie added inline comments.Jan 30 2023, 3:11 PM
llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
422

ah, excellent - the best code is no code. Could you provide a link here to the commit hash/etc that removed it, for the record?

mysterymath marked an inline comment as done.Jan 30 2023, 3:47 PM
mysterymath added inline comments.
llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
422