-
Notifications
You must be signed in to change notification settings - Fork 252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for split debuginfo #287
Comments
I'm all for anything needed to support this! Awhile back I tried to prune the dependencies needed for the |
You're correct that my initial intention with |
I've started looking at the macOS support for this again, and have a rough proof of concept for the One thing it requires (and which I haven't attempted yet) is the ability to read objects in archives. I'm not sure what sort of efficiency/complexity trade-offs we should be making for this. Here's some possible strategies:
For reading archives there is the |
I agree that parsing In any case I think something is better than nothing so having at least a PR or feature to start with sounds good! |
What we have is a list of symbols for each object that was linked in the executable/library. The object is specified by an
|
I think it's fine to basically just throw things onto the LRU cache we already have. It may need to have its size tweaked if there's a huge number of object files in one build to avoid thrashing too much though. |
I think this strategy, or something like it, to at least avoid mapping the same archive multiple times, is worthwhile.
Is there already a crate that handles parsing It is probably worthwhile to at least ensure that whatever you design here won't need major changes to work with DWARF split debuginfo, since that would be a valuable addition. |
As a procedural note, it might be helpful to exhaustively enumerate all the cases we expect this crate to be able to handle gracefully, what's currently supported / needs work, and where new functionality might want to exist. Off the top of my head I can think of:
|
They coexist with other symbols, so existing Mach-O parsers can read them, and it's simple enough to get the information we need without a full stabs debug info parser.
My feeling is that there will be little in common beyond the DWARF parsing itself, which is already done. We currently only support native backtraces, and the parsing of each file format is already separated, so I don't expect much need or possibility for sharing. Thanks for that list. The ELF/Mach-O cases cover everything I know about. I don't know much about PDB. |
FWIW it took time to get the gimli implementation in this crate up to par to include in libstd, so I think it's fine if this takes awhile too. Something to play with is better than nothing at all in my opinion :). I'd be happy to merge basically anything that works behind a feature flag, that way we should have plenty of room to experiment and optimize. |
I've started looking at DWO/DWP support. This will need larger |
The fixes in #401 seem to be enough to get backtraces for rustc's split DWARF support, since the skeleton units still contain location information. I assume we'll still need full DWO/DWP support eventually though. |
This has since been implemented and we're testing it on CI |
As mentioned in rust-lang/rust#34651 (comment), it would be nice if we could generate backtraces when using split debuginfo.
Locating the split debuginfo is something that is useful for all tools that consume DWARF, so I think it makes sense to implement this in another crate. In particular, I think it makes sense to implement this in the
object
crate (perhaps in itsSymbolMap
), because the location of the object files is specified in the symbol table entries for Mach-O (some discussion in gimli-rs/addr2line#87). I haven't investigated split DWARF for ELF yet though, so maybe that will change things.There is also the
moria
crate, but I think it is targeted at stripped debug info that has been installed in a separate location (post dsymutil), rather than the unlinked DWARF (prior to running dsymutil). Maybe we should be handling that too though?The gimli support previously used the
object
crate, but was changed togoblin
in d3fb904. Would it be okay for me to change it back toobject
again? Note that git versions ofobject
no longer depend ongoblin
, so I don't think the original reason for the change applies anymore. The reason for preferringobject
rather thangoblin
is because it is part of thegimli-rs
project, so it is primarily targeted at handling debug info, and many existing consumers of DWARF are already using it. Plus I'm more motivated to work onobject
thangoblin
:)cc @fitzgen
The text was updated successfully, but these errors were encountered: