Padding Bytes between Instructions in Disassembly

[Graggi]

Hi,

I want to learn more on how compiled code is structured on binary level. Therefore, I wrote a simple program that calculates the factorial of a given number and prints it to the monitoring device. I modified the hello world project shipped with ESP-IDF to implement this.

Afterwards, I decompiled the resulting elf-binary (before the transformation to the bin-format that is flashed onto the chip). I did this with two different disassemblers: radare2[1] and the xtensa-specific implementation of objdump[2]. The following screenshots show the disassembly of the factorial function.

disasm-radare2.png (63.55 KiB) Viewed 1138 times

disasm-objdump.png (38.56 KiB) Viewed 1138 times

As you can see, they show different results. To be precise the bytes 0x400e238a (0x00) and 0x400e238b (also 0x00) are skipped by radare while being interpreted as part of an instruction by xtensa-objdump which leads to the next function being misinterpreted. Radare is very clearly correct here.

I assume these are some kind of padding bytes. I could find dozens of other locations in the binary where this happens, but could not figure out any pattern behind it.

My questions are: Why are there padding bytes(?) in the middle of the instruction stream? What is the technical reasoning behind this? And what is the pattern that these bytes occur in?

I could not find any information regarding this in the xtensa isa documentation or the esp32 technical reference manual (though I may have overlooked something, combined they have 1.5k pages).

Regards
Graggi


[1] https://rada.re/n/radare2.html
[2] https://github.com/badgeteam/xtensa-esp ... master/bin

[boarchuz]

Looks like this: https://sourceware.org/binutils/docs/as ... nment.html

"As an optimization to improve performance, the assembler attempts to align branch targets so they do not cross instruction fetch boundaries."

[ccrause]

As a side note: the differences in generated assembly between the two tools are due in part to different scanning algorithms. See e.g. this StackExchange discussion: https://reverseengineering.stackexchange.com/a/2581