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

Greg Clayton via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 20 15:21:39 PST 2023


clayborg 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


I usually often do want to dump and entire binary since I often make small example binaries to test with, so I like the idea of being able to dump all of the DWARF since the skeleton DIE on its own isn't very useful, and dumping the .dwo file without the main executable is only useful if you are not not looking at anything that needs addresses. 

I also would like to search be name, by address and by DIE offset, even if that DIE comes from a DWO file. In LLDB the identifier is a uint64_t and many objects in LLDB map back to the DWARF by specifying a uint64_t that contains the DWO index + 32 bit DIE offset. So I often have a function or variable object that has an indentifier that maps back to DWARF using this DWO idx + DIE offset, and I need to find the exact DWARF.

So I would vote that we allow a way to dump the main executable and all of its .dwo files so we can see fully linked addresses. "--dwo" takes are of this currently.

I also have implemented the main search features I want to use with this patch and hooked it up so it all works with .dwo files.

Let me know your thoughts and or suggestions







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


More information about the llvm-commits mailing list