Remove dladdr fallback and implementation#317
Conversation
This has been present for a very long time but I believe this has never actually been that necessary. Non-MSVC platforms all use libbacktrace by default, and libbacktrace will consult symbol tables of object files to do what `dladdr` does, just inside of libbacktrace. Additionally gimli implements the same logic. I believe that this means that `dladdr` isn't necessary for resolving any symbols since our other strategies should already be doing everything for us. This commit makes the feature defunkt and otherwise removes the various forms of fallback to dladdr.
|
Looks like the gimli implementation doesn't handle fat objects just yet, so that'll need to be handled first. |
alexcrichton
force-pushed
the
rm-dladdr
branch
2 times, most recently
from
6a30541 to
a425c10
Compare
| // | ||
| // It turns out, though, that for system loaded libraries these | ||
| // calculations are correct. For native executables, however, it | ||
| // appears correct. Lifting some logic from LLDB's source it has |
There was a problem hiding this comment.
Should one of these correct be incorrect?
This commit switches the gimli feature from the `goblin` crate to the `object` crate for parsing object files. The main motivation here is trimming the dependencies of the `gimli-symbolize` feature to a bare minimum. The `object` crate itself has no dependencies now and should be a relatively easy drop-in replacement for the `goblin` crate.
This commit updates the object parsing code for macOS to support fat libraries. This enables gimli to symbolize addresses coming from system libraries which are currently installed frequently as fat libraries. Closes #319
This commit fixes an issue where symbolication of system libraries didn't work on macOS. Symbolication through the symbol table was always off by a slide amount for the library. It's not entirely clear why this kept happening or what was going on, but some poking in LLDB's source revealed a way we can differentiate and figure out what addresses need to be looked up in the symbol table. Some more information is contained in the comments of the commit itself. Closes #318
|
Ok, so I'm pretty confident that dladdr is not needed, so I'm going to merge this. When I originally added the dladdr implementation it was ages ago (about the first time I wrote all this). I'm pretty certain that I was calling libbacktrace correctly, misleading me to believe that it was often needed to call dladdr. Nowadays I'm pretty sure that libbacktrace and gimli do everything necessary to implement dladdr, making calling it unnecessary. We may have a few edge cases to work through in the implementation of parsing symbol tables with gimli (or something like that), but it's something we can handle in time. And of course adding dladdr back in is pretty easy to do. In any case this has also snowballed a bit to pick up the Thanks again @philipc for writing the patch to switch to |
2 participants
This has been present for a very long time but I believe this has never
actually been that necessary. Non-MSVC platforms all use libbacktrace by
default, and libbacktrace will consult symbol tables of object files to
do what
dladdrdoes, just inside of libbacktrace. Additionally gimliimplements the same logic. I believe that this means that
dladdrisn'tnecessary for resolving any symbols since our other strategies should
already be doing everything for us.
This commit makes the feature defunkt and otherwise removes the various
forms of fallback to dladdr.