capstone VS bloaty

It just updated to the nearly latest LLVM, so that argument is void: https://github.com/capstone-engine/capstone/blob/next/docs/c...

capstone

Maybe then they can help us with the Capstone[1][2] disassembly engine auto-sync (automatic synchronization from the LLVM TableGen files) effort[3]. ARMv7, ARMv8/9, PowerPC are nearly finished, and MIPS in in near-term plans. Nobody stepped in for RISC-V yet.

[1] http://www.capstone-engine.org/

[2] https://github.com/capstone-engine/capstone

[3] https://github.com/capstone-engine/capstone/issues/2015

Bloaty is a nice tool.

When I worked on Matter a couple years ago, we had the problem that its backend http://www.capstone-engine.org/ did not support Xtensa, and produced some Python tools that could take output from bloaty or similar data from readelf or elftools, and produce several kinds of report.

https://github.com/project-chip/connectedhomeip/blob/master/...

$ git clone -b next https://github.com/capstone-engine/capstone $ cd capstone $ ./make.sh $ sudo ./make.sh install $ cd ..

People already closing in: [Implement an eBPF decompiler/disassembler · Issue #838 · capstone-engine/capstone · GitHub](https://github.com/capstone-engine/capstone/issues/838)

ESP32s aren't really ‘lower level’ in the sense that anyone is likely to write assembly code for them (compared to, say, 8051 or PIC), other than maybe some driver author at Espressif. The big win from using RISC-V, other than name recognition, is mainstream compiler support (which is nothing to sneeze at, especially when it's largely funded by someone else).

When I worked on Matter¹, the Xtensa and RISC-V versions were basically fungible from the software point of view. (And really, so were other vendors' various ARMs.) We did find that Bloaty McBloatface² didn't support Xtensa, so I had to write an alternative.

¹ https://github.com/project-chip/connectedhomeip/

² https://github.com/google/bloaty

I’ve gotten good insight into what takes up space in binaries by profiling with Bloaty (https://github.com/google/bloaty). My last profiling session showed that clang’s ThinLTO was inlining too aggressively in some cases, causing functions that should be tiny to be 75 kB+.

I'm surprised they didn't go for the binary size analysis tools like

https://github.com/google/bloaty

Or goweight.

I was able to shave a few % off our app binary with Bloaty. It’s pretty hard to use but once you figure out how to make regular expressions to properly classify things from your codebase, you can really visually analyze what your binary is composed of.

Bloaty