[llvm] Allow the dumping of .dwo files contents to show up when dumping an e… (PR #66726)

[David Blaikie via llvm-commits]

dwblaikie wrote:

> The main question is, should we get this patch in as is and then add the new options? Or just combine it all here.

I think figuring out the overall design is a good idea then figure out what the implementation strategy is.

One argument could be made that a "dump everything" mode might not be what we want (if it is what you want, that's OK - we can do that)

I wonder if we didn't do that/didn't add any new flags, and improved the existing search flags 

> Also from a testing perspective, how can I add a filename + .dwo test that is portable?

There's lots of existing testing of Split DWARF (for LLVM output, and for llvm-dwarfdump/llvm-symbolizer/etc) - best to take a look at that for inspiration (from a previous/recent discussion, the sort of preference for implementation strategies these days is to use yaml (yaml2obj to create the inputs), assembly (llvm-mc run in the test to assemble it), or LLVM IR in that order of reduced preference/less isolated testing)

>  The DWO name is usually a full path and I am not sure that relative file paths are supported by the llvm stuff? 

Relative paths are supported and used exclusively at Google, for instance - it's the only way to make portable/directory-independent reproducible builds.

> If we are testing this in llvm, then we can't use clang in the tests right? 

Right

> So I would need to either run obj2yaml on the main executable and .dwo file, but then I still end up with problems with the .dwo path being hard coded

If you were generating this from clang, you can use -fdebug-compilation-dir=. to make the paths relative, or you can modify the assembly or yaml after the fact.


https://github.com/llvm/llvm-project/pull/66726