Add Line to Address Functionality

[FlyingCanoe]

I was in the process of trying to write lines to address functionality for headcrabe and I was having trouble. So I decide to read through the addr2line code to familiarize myself with some prior art on how to deal with DWARF. And I realize that the bulk of the code that would be needed for the line to address future was already existed in this repo. In fact, I created a working bad prototype that added only 31 line.

That being said, there some are some potential issue with implementing such future in this crate. I was able to spot 3 issues: performance, what API would be best and if this is the right project for this kind of functionality.

Performance

I expect that calling the line to address functionality will be significantly more expensive than the rest of the functionality in this crate. This cost would also probably be particularly felt the first few times it is call has the change that the mapping you are searching is not already cache is higher. It is also possible that I am wrong in that front and that an efficient implementation would not be that expensive.

The API

I was thinking of two functions.

One were you give the file path and the line number and it return the list of address of the instruction in that line.

The other function would work like the first one but you would also provide it with a column number .
I guessed you could also have a function that work at the file level, but I don’t think it would be that useful. I am honestly unsure if those two functions would provide the best API. In this area I think that your feedback could be particularly valuable.

Is this the right project?

Has I understand it, the aim of this project is to provide functionality similar to binutis addr2line.
And the binutis addr2line do not provide line to address functionality (I think, I have never used this program but since I could not find anything about some line to address functionality in the man page I assume it didn't have any). There is also the name, providing line to address functionality in a crate name add2line could seem a bit silly. So it leads to the question of if another gimli project would be better suited to harbors this functionality or if it would be better for headcrabe to have its own fork that extent the future of this crate to things that are considered out of scope for this project.

I think this sum up the main concern over this future. Of curse, it is possible that I have missed some concerns or that new one apart once a start crating a proper implementation. If you find anything that I miss I would be happy to get some feedback.

[philipc]

I expect that calling the line to address functionality will be significantly more expensive than the rest of the functionality in this crate.

It certainly will be slow if it requires brute force searches for the file and line. I think you should be able to do better than that, but it will probably require invasive changes to this crate. Perhaps you could look at the source for gdb and lldb and see how they solve this. Also have a look at probe-rs which also uses gimli. It is still kind of brute force, but it first checks that the filename is present in the unit.

One were you give the file path and the line number and it return the list of address of the instruction in that line.

Sounds reasonable.

Is this the right project?

It's probably not the right project for line to address functionality.

Also, the current design of this crate isn't great for use in something like headcrab. A debugger will need to use the DWARF for much more than line number information, whereas this crate attempts to hide all of the DWARF details.

I suggest that you start with a fork, and once you know what you need we can see if it makes sense to redesign the API of this crate to allow you to reuse some of it.

[philipc]

Out of scope currently.