Vibe coding an ELF tool
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::fmtin 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.