This is an archive of the discontinued LLVM Phabricator instance.

[llvm-dwp] Join dwo paths correctly when DWOPath is absolute
ClosedPublic

Authored by nagisa on Feb 14 2021, 4:56 PM.

Details

Summary

When the DWOPath is absolute, we want to use DWOPath as is, without prepending any other
components to the path. The sys::path::append does not join, but rather unconditionally appends
the paths, so something like sys::path::append("/tmp", "/tmp/banana") will result in
/tmp/tmp/banana rather than the desired /tmp/banana.

This then causes llvm-dwp to fail in a following situation:

$ clang -gsplit-dwarf /tmp/banana/test.c -c -o /tmp/outdir/foo.o
$ clang outdir/foo.o -o outdir/hm
$ llvm-dwarfdump outdir/hm | grep -C2 foo.dwo
                  DW_AT_comp_dir    ("/tmp")
                  DW_AT_GNU_pubnames  (true)
                  DW_AT_GNU_dwo_name    ("/tmp/outdir/foo.dwo")
                                DW_AT_GNU_dwo_id    (0xde4d396f3bf0e257)
                  DW_AT_low_pc  (0x0000000000401100)
$ strace -o trace llvm-dwp -e outdir/hm -o outdir/hm.dwp
error: No such file or directory
$ cat trace | grep foo.dwo
openat(AT_FDCWD, "/tmp/tmp/outdir/foo.dwo", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

Diff Detail

Event Timeline

nagisa requested review of this revision.Feb 14 2021, 4:56 PM
nagisa created this revision.
Herald added a project: Restricted Project. · View Herald Transcript

Note: I do not have a commit bit, if approving this, please also commit.

Please add/include test coverage.

llvm/tools/llvm-dwp/llvm-dwp.cpp
529–530

Generally prefer = init syntax over {} or () (this avoids any invocation of explicit conversions, for instance - making the code a bit simpler/easier to understand)

nagisa updated this revision to Diff 323833.Feb 15 2021, 2:42 PM

Add a test for llvm-dwp operation with absolute paths

nagisa updated this revision to Diff 323834.Feb 15 2021, 2:42 PM

diff with lint

Please add/include test coverage.

Added a test and verified it reproduces the issue without this change and passes now. Let me know if this approach is not what you were thinking of.

llvm/tools/llvm-dwp/llvm-dwp.cpp
529–530

The = fails to build, because the conversion is necessary (DWOName is a std::string). Is there a better way to get this conversion happen?

nagisa updated this revision to Diff 323836.Feb 15 2021, 2:50 PM

Remove some fluff from the test llvm-ir

dblaikie added inline comments.Feb 16 2021, 10:54 AM
llvm/test/tools/llvm-dwp/X86/absolute_paths.test
5

Should this have some CHECKs for certain behavior (dumping the resulting dwp and checking things, for instance)

"does something other than crashing/failing" is a pretty low bar for a test, doesn't especially check that this behaves in a way we would want it to.

llvm/tools/llvm-dwp/llvm-dwp.cpp
529–530

Ah, no, that's fine then. I'd /probably/ lean towards using () rather than {} then, because there's been no wide-scale stylistic tendency towards {} for ctors in LLVM, but not a huge deal.

nagisa updated this revision to Diff 324066.Feb 16 2021, 11:21 AM

Add some filecheck to the test and change the constructor style

nagisa added inline comments.Feb 16 2021, 11:22 AM
llvm/test/tools/llvm-dwp/X86/absolute_paths.test
5

I added some CHECK lines that should at least verify that the llvm-dwp picks up the right dwo file (by the virtue of both the files having (mostly?) the same contents).

I had a pretty hard time coming up with something more meaningful than that.

dblaikie accepted this revision.Feb 16 2021, 11:55 AM

Sounds good, thanks for walking me through it.

(as a heads up: llvm-dwp isn't great (I wrote it years ago to mitigate some risk with binutils dwp memory usage which ended up being resolved otherwise) - specifically I don't think it's ever been used in any production use case that I know of, has I believe significantly worse runtime/memory usage than binutils/gold dwp and while neither supports DWARFv5, I do have some patches I need to upstream to add DWARFv5 support for binutils/gold dwp

At some point llvm-dwp probably will be/needs to be rewritten, probably using some of lld's infrastructure (in a similar way to binutils/gold dwp uses some gold infrastructure) to reduce overheads.

But small patches with tests like this aren't too bad and the tests will ensure we preserve the functionality during any such rewrite in the future)

llvm/test/tools/llvm-dwp/X86/absolute_paths.test
9–16

Maybe only dump/test the debug_info section ( llvm-dwarfdump %t/test.dwp should do that, only dumping the debug_info section by default) and check DW_AT_subprogram has a DW_AT_name of "banana" - would check this specific dwo file was included in the dwp (& indirectly exercises a bunch of other functionality, like index usage, strings, abbreviations, etc).

This revision is now accepted and ready to land.Feb 16 2021, 11:55 AM
nagisa updated this revision to Diff 324076.Feb 16 2021, 12:06 PM

Check the formatted output from dwarfdump instead

nagisa updated this revision to Diff 324090.Feb 16 2021, 1:13 PM

revert the test to its previous form

Just so that it doesn't get lost between hidden comments: I've no commit bit, please commit this for me if this is good to go.

llvm/test/tools/llvm-dwp/X86/absolute_paths.test
9–16

Looks like doing so doesn't work out in this particular test. On windows the dwarfdump output gets escaped in a way and -DPATH that we pass in is not escaped (the same way). cf. this. I'm not seeing a good way to match the string so I'm going to keep the test as it was originally written.

nagisa marked 3 inline comments as done.Feb 16 2021, 1:15 PM
This revision was landed with ongoing or failed builds.Feb 16 2021, 1:38 PM
This revision was automatically updated to reflect the committed changes.