3 ms·

Analyzing ELF symbols using SQL

76 points by setheron 3y ago

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 ago
  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.
- aleden 3y ago
  Personally I regard llvm-readobj and llvm-objdump as the state of the art. They are very well written.
- setheron 3y ago
  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.
mistrial9 3y ago
static analysis | filters | sql_db ## done that this reads running binaries and gets link symbols? linux
- setheron 3y ago
  this is more about doing it on the fly.
cmrdporcupine 3y ago
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. Sorry, old-man-me is feeling unwell today, back to bed to take a nap.

76 points by setheron 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 ago
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.
aleden 3y ago
Personally I regard llvm-readobj and llvm-objdump as the state of the art. They are very well written.
setheron 3y ago
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.

mistrial9 3y ago

static analysis | filters | sql_db ## done that this reads running binaries and gets link symbols? linux

setheron 3y ago
this is more about doing it on the fly.

cmrdporcupine 3y ago

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. Sorry, old-man-me is feeling unwell today, back to bed to take a nap.