Accessing DWARF information from C++

Stefan_Kratochwil · October 13, 2015, 9:42am

Hi altogether,

I currently am developing an application where I need to access the DWARF debugging information of my target process and its loaded .so files.

In more detail, I need to match type information of certain entities within my code and its dynamically linked libraries.

I already use the lldb scripting bridge in my application, hence I would like to use lldb's DWARF parsing capabilities in my application, too.

Now, there is no (obvious) way to extract DIEs using the C++ API, so I need a few hints where to start. Does anyone have a minimal example for simply dumping DWARF info in a 'readelf -w' manner?

I further discovered another DWARF implementation within the llvm sources. After some investigation I found this discussion on lldb-dev:
http://lists.cs.uiuc.edu/pipermail/lldb-dev/2014-June/004197.html

Does anybody know if there is already some effort made to implement a lldwarf solution as a replacement for both mentioned implementations?

And, after going through the discussion, is it probably better for me to use the llvm fork?

Thanks in advance!

Cheers,
Stefan

Stefan_Kratochwil · October 13, 2015, 4:03pm

Hi,

well, I found the llvm-dwarfdump tool in the tools directory *facepalm*...
I'll use that as a reference.

That leaves the question about the two separate DWARF implementations.

Cheers,
Stefan

jingham · October 13, 2015, 6:05pm

Hi,

well, I found the llvm-dwarfdump tool in the tools directory *facepalm*...
I'll use that as a reference.

That leaves the question about the two separate DWARF implementations.

Ideally it would be good to try to merge the two implementations. However, lldb's usage patterns - doing focused queries, only unpacking as little of the DWARF as it can possibly manage to satisfy such queries, etc, are very different from those of a straight up dumper. N.B. if you're not very careful how you handle debug information in the debugger you can get really dramatic performance problems particularly with large projects. Since this is so crucial, we (mostly Greg) built lldb's DWARF reader as an experiment in supporting those patterns as efficiently as possible, rather than as a general purpose library. So replacing the current implementation is not a task to be undertaken lightly. To date, there hasn't been a compelling reason to do that work as opposed to all the other interesting stuff we could be doing.

Jim

Greg_Clayton1 · October 13, 2015, 10:15pm

Hi altogether,

I currently am developing an application where I need to access the DWARF debugging information of my target process and its loaded .so files.

In more detail, I need to match type information of certain entities within my code and its dynamically linked libraries.

I already use the lldb scripting bridge in my application, hence I would like to use lldb's DWARF parsing capabilities in my application, too.

Now, there is no (obvious) way to extract DIEs using the C++ API, so I need a few hints where to start. Does anyone have a minimal example for simply dumping DWARF info in a 'readelf -w' manner?

We don't dump DWARF unless it is done by enabling DWARF logging, but that won't help you. So if you want to just dump dwarf, use lldb-dwarfdump.

I further discovered another DWARF implementation within the llvm sources. After some investigation I found this discussion on lldb-dev:
http://lists.cs.uiuc.edu/pipermail/lldb-dev/2014-June/004197.html

Does anybody know if there is already some effort made to implement a lldwarf solution as a replacement for both mentioned implementations?

LLDB provides a debug info agnostic abstraction. If you want actual raw DWARF, then you should use llvm's DWARF parser. llvm's DWARF parser was created by copying the LLDB version and trimming it down. It was initially done to get to file and line info in the .debug_info, but it has been expanded since.

And, after going through the discussion, is it probably better for me to use the llvm fork?

So this depends on how DWARF specific you need things. With LLDB, you can lookup types by name and get a SBType back that can give you all of the info that DWARF will give you. You can get SBFunction objects that describe functions, you can lookup an address and get a SBSymbolContext which will give you access to the SBModule (object file), SBCompileUnit, SBFunction, SBBlock, SBLineEntry and SBSymbol. So you will be able to use LLDB to do specific queries, but we won't give you exact DWARF access. So if you use LLDB depends on what you are looking to get from the debug info. Can you clarify what kinds of queries you will be making? I might be able to tell you if you will be able to do them with our public API.

Greg

Stefan_Kratochwil · October 30, 2015, 10:35am

Hi Greg,

thanks for your reply.

I am developing a dynamic software updating tool for dynamically linked C libraries (in short: I want to patch dynamic libraries in-memory).

My goal is to achieve that without any code instrumentation. The main problem is the state transformation between the old and the new version - here I need as much type (and location) information as possible.

I am currently unaware of what types of information I _really_ need, so for now, getting as much information as possible is my way to go. I guess that the most important types of information will be:
- size of primitives
- size of pointers
- type hierarchies and
- the in memory-structure of compound data types

At the moment I am concentrating on the Linux / UNIX domain, so DWARF is my preferred format.

Cheers,
Stefan

Greg_Clayton1 · November 3, 2015, 8:14pm

This is all available through the LLDB API, so I would suggest using LLDB and its debug info agnostic APIs. Let me know if you need to know how to find certain kinds of information from our API and I can help get you up and running.

Greg Clayton

Frank_Ch_Eigler · November 3, 2015, 9:16pm

Stefan Kratochwil wrote:

[...]
I am developing a dynamic software updating tool for dynamically
linked C libraries (in short: I want to patch dynamic libraries
in-memory).