12587603 OS disassembly

[antus]

Yeah that's decompiled code, rather than disassembled. There is a lot of information lost in the compile process and its an incredibly difficult task to rebuild the C code that generated the machine code in a generic way due to differences in all compilers, versions, optimisations and CPU architectures. Hexrays (from Ida, but a very expensive add on) is better at it than Ghidra's decompiler, but Hexrays does not support CPU32 / 68K so you can't even get anything that resembles C code for that CPU on Ida / Hex rays at all. When working with x86/arm or another supported architecture its better. Decompilation for assembly back to C is really best to get hints to understand high level logic flow when the assembly looks like a mess, it's rare to get complete and perfect C output and really only happens on small and simple functions.

Edit: the elf contains the compiled code, but has C as debug code in it also so the disassembler can inline the source. But to just spit out the source verbatim wouldn't help for a tool like this as its all about the binary so I assume that's the justification for not developing anything that can using more of the line by line source code data when available in the decompiler. Most the use cases for the tool are to use it when you do not have source code or debug data available.

[pman92]

As antus mentioned the ELF file is still the compiled code.
Try building your arduino project with no optimisation and see how it looks (you'll have to do it manually via command line rather than Arduino IDE probably).

I've noticed the decompiled output in Ghidra for power PC is great.
The output for another HC08 project I was working on wasn't so good. It was logical but hard to read. It didn't deal with pointers very well

[AngelMarc]

Command line? thanks for the warning, now I know to just not.