Analyzing ELF symbols using SQL | Hacker News Reader

Analyzing ELF symbols using SQL

fzakaria.com

76 pointssetheron7 comments

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)

ldd 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.

Personally I regard llvm-readobj and llvm-objdump as the state of the art. They are very well written.

author 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.

In my ideal world all system utilities (and many applications) output relational tuples, and the shell includes a relational algebraic query tool --equivalent to SQL, but with a more composable syntax. Instead of awk'ing and grepping, we'd be doing Restrict, Join, Union, and Project on the output of anything, and there'd be no need to be dumping into a separate database system just to be able to have access to the kind of recomposable, queryable, consistent, discoverable information management that is every user's right since Codd first penned “A Relational Model of Data for Large Shared Data Banks.” in 1970.