This is an archive of the discontinued LLVM Phabricator instance.

[llvm-dwp] Add command line option "-e"
ClosedPublic

Authored by alexander-shaposhnikov on Aug 31 2017, 10:52 PM.

Details

Summary

The binutils utility dwp has an option "-e" https://gcc.gnu.org/wiki/DebugFissionDWP
to pass an executable / library (to get the list of dwo files from it).
This option is particularly useful when someone runs the tool manually outside of a build system
(passing the full list of dwo files is not convenient).
This diff adds an implementation "-e" to llvm-dwp.

Test plan: make check-all

Diff Detail

Repository
rL LLVM

Event Timeline

Apply clang-format.

grimar edited edge metadata.Sep 1 2017, 2:29 AM

Few comments below.

test/tools/llvm-dwp/X86/dwos_list_from_exec_simple.test
6 ↗(On Diff #113510)

Please specify compiler and command line used.

tools/llvm-dwp/llvm-dwp.cpp
474 ↗(On Diff #113510)

I would add few empty lines to this function to separate code blocks.

490 ↗(On Diff #113510)

I think SmallString<16> would be more common.

491 ↗(On Diff #113510)

I believe it is excessive to reserve here.

493 ↗(On Diff #113510)

Here is a bug. DWOPatch.data() will return pointer to internal buffer, but not a string.
It can be not nul-terminated.

You may use following to fix probably:

DWOPaths.emplace_back(DWOPath.data(), DWOPath.size());
717 ↗(On Diff #113510)

It seems this will fail if you run tests with LLVM_ENABLE_ABI_BREAKING_CHECKS.
You need to check Expected<>:

auto DWOs = getDWOFilenames(ExecFilename);
if (!DWOs) {
...

Otherwise if should fail:
https://github.com/llvm-mirror/llvm/blob/master/include/llvm/Support/Error.h#L507
https://github.com/llvm-mirror/llvm/blob/master/include/llvm/Support/Error.h#L636.

address code review comments,
fix a bug.

alexander-shaposhnikov marked 6 inline comments as done.Sep 1 2017, 7:02 AM

@grimar - many thanks for the review - good catches ! (+ i was too sleepy)

alexander-shaposhnikov edited the summary of this revision. (Show Details)Sep 1 2017, 11:07 AM
dblaikie added inline comments.Sep 1 2017, 11:54 AM
test/tools/llvm-dwp/X86/dwos_list_from_exec_simple.test
4 ↗(On Diff #113539)

Yeah, it's difficult/not quite possible to stream out ELF files (because the header has to point to the section headers, which are emitted at the end of the file so they can contain all the section sizes... (you could do a prepass to compute all these things then you could stream output)) - Clang (& maybe the llvm tools like llvm-mc, etc - not sure, haven't checked them) avoids this by writing to a temp file then streaming the temp file out through stdout or whatnot. llvm-dwp doesn't have that functionality, but could be taught it, maybe. (might be useful if it were optional, for those who don't want to burn more file IO/space, etc)

tools/llvm-dwp/llvm-dwp.cpp
57–60 ↗(On Diff #113539)

Wonder if this even needs a separate argument - would it be reasonable to detect which case this is in? (probably not by file extension, but by contents? Not sure... maybe that'd be hard/annoying/not much use)

725–727 ↗(On Diff #113539)

Seems weird to ignore all the other inputs silently if -e is specified. Maybe error out if there are both?

Alternatively could support both, maybe - more like what I mentioned above, even. Could detect that something is an executable/contains skeleton units - use those to find DWOs, and treat that as another source of DWOs (so you could have arbitrarily many executables and DWOs on the command line and they'd all be read and smooshed into a DWP).

*shrug* Dunno.

What does binutils dwp do if you have both -e and .dwo files? Error?

tools/llvm-dwp/llvm-dwp.cpp
725–727 ↗(On Diff #113539)

yeah,
i've just looked at binutils dwp ( 2.25.1-22.base.el7).
Actually binutils dwp behaves differently, it takes everything, i.e.

[alexshap@devvm32123.prn1 ~/fission/build] dwp c.dwo -e out/libFoo.so -o test.dwp
[alexshap@devvm32123.prn1 ~/fission/build] cat c.cpp
struct XXXXXX {
  int YYYYYY;
 };

 int ZZZZZZ() {
   XXXXXX x;
   return x.YYYYYY;
 }
 [alexshap@devvm32123.prn1 ~/fission/build] strings test.dwp | grep ZZZZZZ
 ZZZZZZ
 _Z6ZZZZZZv

additionally, binutils dwp allows to pass -e multiple times.

so yes, we can try to replicate this behavior (that looks easy),
alternatively, we can try to avoid introducing this new flag and try to extract the necessary information from the files themselves (i agree, this probably would be cleaner, on the down side - requires more work/a bit more complex logic + switching back and forth from bintutils version to llvm will require changing the invocation) @dblaikie - how should we proceed ?

Allow using multiple sources of dwos

dblaikie added inline comments.Sep 1 2017, 3:03 PM
test/tools/llvm-dwp/X86/dwos_list_from_exec_simple.test
1 ↗(On Diff #113597)

Should probably include a direct .dwo file in this test as well? (maybe multiple .dwo and executables, ideally - to demonstrate/test that they're both supported in plurals)

tools/llvm-dwp/llvm-dwp.cpp
715 ↗(On Diff #113597)

Prefer:

std::vector<std::string> DWOFilenames = InputFiles;

(if that compiles... ) rather than direct init.

718–721 ↗(On Diff #113597)

Does binutils dwp error on this, or ignore the executable?

tools/llvm-dwp/llvm-dwp.cpp
718–721 ↗(On Diff #113597)

[alexshap@devvm32123.prn1 ~/fission/build] dwp c.dwo -e out/libFooDoesNotExist.so -o test.dwp
dwp: error: cannot open out/libFooDoesNotExist.so: No such file or directory
dwp: fatal error: out/libFooDoesNotExist.so: can't open

binutils dwp reports an error on this.

alexander-shaposhnikov marked 2 inline comments as done.Sep 1 2017, 3:47 PM
dblaikie accepted this revision.Sep 1 2017, 3:53 PM

Some things to tidy up in the test, some optional.

test/tools/llvm-dwp/X86/dwos_list_from_exec_simple.test
16–18 ↗(On Diff #113617)

You could simplify these a bit by just making them void:

void a() {}

etc.

21–26 ↗(On Diff #113617)

Could have main here and drop 'b', I'd expect.

43–68 ↗(On Diff #113617)

Is it worth checking the abbrevs? Seems like it might be enough to just check the DW_AT_names?

76 ↗(On Diff #113617)

This seems wrong - you're not using the DWOA value, and you're rematching it on every dwo_id? Probably skip that.

This revision is now accepted and ready to land.Sep 1 2017, 3:53 PM

Simplify the test a bit.

@dblaikie - many thanks for the code review

Update the binaries used by the test and document the hack used to generate "portable" binaries.

I have not committed this diff yet and will keep this open for some time since the problem with the test
might be of independent interest.
Notes:

  1. obj2yaml + sed + yaml2obj doesn't seem to be an option at this point

(we need to edit the debug info, obj2yaml dumps dwarf just as hex).

  1. running the compiler + linker doesn't seem to be an option (since this is an llvm test).
  2. the approach chosen below (while being hacky) only requires some efforts at the data preparation step and is quite simple,

thus it seems to be the smaller evil than other options are,
however i assume i could have missed something.

Rebuild the test binaries,
make use of -fdebug-compilation-dir.
Rerun the tests.

This revision was automatically updated to reflect the committed changes.