3 ms·
This looks like an interesting and useful approach, but there's no need to overdo the claims: > Which library that I load is providing function foo? > The sta
by gumby 3y ago
This looks like an interesting and useful approach, but there's no need to overdo the claims:
> Which library that I load is providing function foo?
> The state of the art (prior to sqlelf) of how to retrieve this diagnostic information is using LD_DEBUG environment variable and trolling through the large dump of logs it emits
That's far from the state of the art. Just use a tool like ldd or otool to get a list of dependencies, loop a call to nm over that and grep for the symbol you want. It's a one liner that gives you the answer (and tells you which other libraries export the same symbol, in case you need to reorder the library loading).
Nevertheless I regret not putting higher resolution file metadata support into bfd. Objdump is more oriented to the content of the sections, and some section metadata, but there's a lot of interesting and fun stuff in the ELF file header (not that ELF existed back then)
- pcstl 3y agoldd itself, at least on most Linux variants, is simply a wrapper around setting the LD_TRACE_LOADED_OBJECTS environment variable and then running the wrapped command, which can bite people in the ass, as it assumes that the code being run by ldd will respect the environment variable.
- aleden 3y agoPersonally I regard llvm-readobj and llvm-objdump as the state of the art. They are very well written.
- setheron 3y agoauthor here: it's a bit over the top I admit but the point to get across is that having a DB, and specifically SQL, over which to do your analysis is game changing. That in of itself is not new, that's why databases were invented :) The idea here is bringing this to the linux low-level toolkit which hasn't seen (historically) much change. You could imagine software that interacts with ELF as well.