David Park

Vibe coding an ELF tool

· elfq, part 1 · elf, tooling

nm -S and bloaty tell you how big each function in a binary is. They don’t tell you things like:

  • If I removed process_frame, how many bytes would go away with it?
  • Why is core::fmt in the binary at all?

To answer those, you have to follow every call and every pointer from where the program starts. None of the common tools answer them on a normal binary, so I’m building one: elfq, short for “ELF query”. It skips flat size breakdowns, since bloaty already does those well.

elfq is 100% vibe coded. Claude wrote all of the code and the docs.

How it’s gone so far:

  • Before any code, we ran the tools that already exist (binutils, bloaty, twiggy, radare2 and a few others) on the same sample binaries and wrote down what each one could answer. The closest was twiggy, but on ELF it needs a binary linked with --emit-relocs, which most aren’t, and even then it got some of the samples wrong.
  • The samples are small C, C++ and Rust programs for x86-64 and Cortex-M. Each function in them covers one case, like a shared helper or a call through a pointer, so the tests can check elfq against known answers.
  • Then it was one PR at a time. 30 so far, in under a week.
  • Some of the later ones just made the output shorter and clearer.

It works on x86-64 programs and Cortex-M firmware, with or without debug info, and even stripped. The next part is about how it finds the answers.