Wow, having to stare at disassembly too often, I really like this.
Makes it much faster to follow branches and can easily see what instructions correspond to source code lines, even though it's not very exact at higher optimization levels.
With recent versions of GNU objdump, you can use --source --visualize-jumps=color and perhaps also --reloc or --dynamic-reloc for a similar experience with the native toolchain. (Unfortunately, -S/--source absolutely sucks for executables compiled at -O2.)
Other tricks include --no-addresses --no-show-raw-insn, which make the disassembly decently diffable.
Did you have debug symbols? I assume you probably passed -g, but the debug info can still not be compatible sometimes. I know when using lldb I sometimes have to force dwarf debug info or -ggdb to get it working.
Yeah, at the moment, unfortunately only works for Go.
But implementing a different backend (e.g. llvm-symbolizer, objdump etc.) shouldn't be too difficult. The main things it needs to do are 1. list the decompilable symbols in the file, 2. disassemble and pull in the relevant source code.
Love lensm! I've used it on several occasions to teach people about inlining, bounds check removals, and other performance related topics that are best highlighted by actually seeing differences in assembly. I find it's easier for people to understand what is actually happening under the hood than just tell them "do this and it's faster".
I also highly recommend following the creator. I'm always impressed with anything Egon creates.
18 comments
[ 4.7 ms ] story [ 49.4 ms ] threadMakes it much faster to follow branches and can easily see what instructions correspond to source code lines, even though it's not very exact at higher optimization levels.
This should be integrated in all IDEs.
Other tricks include --no-addresses --no-show-raw-insn, which make the disassembly decently diffable.
It's meant for reverse engineering but I use it for debugging purposes too
Though I haven't tried it, on mobile right now.
But implementing a different backend (e.g. llvm-symbolizer, objdump etc.) shouldn't be too difficult. The main things it needs to do are 1. list the decompilable symbols in the file, 2. disassemble and pull in the relevant source code.
The UI part doesn't care whether it's Go or not.
https://news.ycombinator.com/item?id=32138111 - Lensm, a Tool for Viewing Disassembly (2022)
https://news.ycombinator.com/item?id=32133394 - Lensm: Go Assembly and Source Viewer (2022)
I also highly recommend following the creator. I'm always impressed with anything Egon creates.