Supporting offline symbol resolution

[Lectem]

Hello,

I am currently using libbacktrace for the following reasons:

• the license (libbfd can't really be shipped in anything professional)
• its ease of use
• its code is way easier to read than binutils'

And so far it's great!

However I'm reaching a point where I'd like to be able to do symbol resolution once the process is dead.

I already save the necessary information required to identify files that are needed (usually file path / buildid) and realized there is not a lot of things missing to make libbacktrace support symbol resolution out of process. The idea is that instead of "invading" the process (I'm stealing Windows' DbgHelp term here) and load information for the current process, the user could create a session (state) for any process it wants, and load debug information using the recorded file/buildid + base address.

Would you be open to the idea of adding an API to support such use case?

I can see two obstacles for this:

• it will make the library a bit bigger / out of scope
• we may want to support all formats variation at the same time at some point, not just the current one (so that for example you can resolve symbols of coff on a machine using elf). This is however not necessary in a V1.

I do believe (at least from what I read so far) it will not be that much work, which I'm ready to do. So my question mostly is, should I just hack it for my personal use, or is it something you would welcome upstream?

Thanks a lot.

[ianlancetaylor]

This sounds like what, for example, the addr2line program does. libbacktrace currently fills a specific niche, I'm not sure it needs to expands to other areas. I'm open to counter-arguments.

[Lectem]

Yeah it's mostly what addr2line does, but addr2line requires spawning a new process for every single image file and will reopen it all the time, so it's kind of slow (and requires parsing gymnastics).
Another issue with it is that you cant specify a buildid / guid to make sure you are using the correct file.

My use case is for profilers / real-time monitoring. Instead of doing the symbol resolution in the process itself, you just keep/send the base address and paths of the loaded libraries (and executable) + the actual callstack pointers. This also means you do not need to ship actual debug files with full symbols.
That way another machine can resolve them later on. There can be quite a lot of those symbols, and you may want to do this real-time, which doesn't make a tool like addr2line really suited. Also libbfd is under GNU license which means limiting projects under which you can use it.

The other reason is simplicity (from the user point of view) : libbacktrace already has almost everything we'd want:

• buildid file lookup and check
• caching / fast resolution
• support for the major binary formats
• already a dependency since used to get backtraces, why add another one that almost duplicates its code
• permissive license