Curly brackets in xtensa dissasembly

Question

I'm dissassembling and inspecting (mostly for fun and learning) the Arduino code generated for an ESP8266 (Xtensa ISA).

I've been following the code so far without issues until the curly brackets (location 4010f4c2) in the main function:

4010f494 <main>:
4010f494:   90a092                  movi    a9, 144
4010f497:   c01190                  sub a1, a1, a9
4010f49a:   00a022                  movi    a2, 0
4010f49d:   236102                  s32i    a0, a1, 140
4010f4a0:   2261c2                  s32i    a12, a1, 136
4010f4a3:   2161d2                  s32i    a13, a1, 132
4010f4a6:   ffc2c5                  call0   4010f0d4 <print_version>
4010f4a9:   202110                  or  a2, a1, a1
4010f4ac:   001045                  call0   4010f5b4 <eboot_command_read>
4010f4af:   00d256                  bnez    a2, 4010f4c0 <main+0x2c>
4010f4b2:   024c                    movi.n  a2, 64
4010f4b4:   fee101                  l32r    a0, 4010f038 <_stext+0x38>
4010f4b7:   0000c0                  callx0  a0
4010f4ba:   1d0c                    movi.n  a13, 1
4010f4bc:   000506                  j   4010f4d4 <main+0x40>
4010f4bf:   af2200                  excw
4010f4c2:   2200a0d2016122ff    { l32r  a15, 400e794c <__udivsi3+0xd9730>; excw }
4010f4ca:   d97ea0                  excw
4010f4cd:   da0121                  l32r    a2, 40105cd4 <__udivsi3+0xf7ab8>
4010f4d0:   9c0c11280000c0fe    { excw; excw; srli  a0, a12, 12 }
4010f4d8:   5a1266                  bnei    a2, 1, 4010f536 <main+0xa2>
4010f4db:   feda21                  l32r    a2, 4010f044 <_stext+0x44>
4010f4de:   fecc01                  l32r    a0, 4010f010 <_stext+0x10>
4010f4e1:   0000c0                  callx0  a0
4010f4e4:   fedd01                  l32r    a0, 4010f058 <_stext+0x58>
4010f4e7:   0000c0                  callx0  a0
4010f4ea:   3138                    l32i.n  a3, a1, 12
4010f4ec:   4148                    l32i.n  a4, a1, 16
4010f4ee:   2128                    l32i.n  a2, a1, 8
4010f4f0:   050c                    movi.n  a5, 0
4010f4f2:   ffcec5                  call0   4010f1e0 <copy_raw>
4010f4f5:   02cd                    mov.n   a12, a2
4010f4f7:   fed901                  l32r    a0, 4010f05c <_stext+0x5c>
4010f4fa:   0000c0                  callx0  a0
4010f4fd:   fed221                  l32r    a2, 4010f048 <_stext+0x48>
4010f500:   0c3d                    mov.n   a3, a12
4010f502:   fec301                  l32r    a0, 4010f010 <_stext+0x10>
4010f505:   0000c0                  callx0  a0
4010f508:   acec                    bnez.n  a12, 4010f536 <main+0xa2>
4010f50a:   f27c                    movi.n  a2, -1
4010f50c:   1129                    s32i.n  a2, a1, 4
4010f50e:   3128                    l32i.n  a2, a1, 12
4010f510:   2129                    s32i.n  a2, a1, 8
4010f512:   2dec                    bnez.n  a13, 4010f538 <main+0xa4>
4010f514:   fece21                  l32r    a2, 4010f04c <_stext+0x4c>
4010f517:   febe01                  l32r    a0, 4010f010 <_stext+0x10>
4010f51a:   0000c0                  callx0  a0
4010f51d:   2128                    l32i.n  a2, a1, 8
4010f51f:   ffbf05                  call0   4010f110 <load_app_from_flash_raw>
4010f522:   02cd                    mov.n   a12, a2
4010f524:   203220                  or  a3, a2, a2
4010f527:   feca21                  l32r    a2, 4010f050 <_stext+0x50>
4010f52a:   feb901                  l32r    a0, 4010f010 <_stext+0x10>
4010f52d:   0000c0                  callx0  a0
4010f530:   0003c6                  j   4010f543 <main+0xaf>
4010f533:   000000                  ill
4010f536:   4d8c                    beqz.n  a13, 4010f53e <main+0xaa>
4010f538:   201110                  or  a1, a1, a1
4010f53b:   000d05                  call0   4010f60c <eboot_command_clear>
4010f53e:   1128                    l32i.n  a2, a1, 4
4010f540:   d00226                  beqi    a2, -1, 4010f514 <main+0x80>
4010f543:   5c9c                    beqz.n  a12, 4010f55c <main+0xc8>
4010f545:   fec341                  l32r    a4, 4010f054 <_stext+0x54>
4010f548:   f37c                    movi.n  a3, -1
4010f54a:   0020c0                  memw
4010f54d:   002422                  l32i    a2, a4, 0
4010f550:   013310                  slli    a3, a3, 31
4010f553:   202230                  or  a2, a2, a3
4010f556:   0020c0                  memw
4010f559:   006422                  s32i    a2, a4, 0
4010f55c:   ffff06                  j   4010f55c <main+0xc8>

I saw this before but I wasn't to bothered about it until the code reached the location 4010f4af with a branch instruction to 4010f4c0 which sit well in the middle of the curly brackets. Of course even with this, if I try to apply the parsing logic, over this byte location I get ffaf22 which corresponds to the valid instruction movi a2, 0xfff.

This code belongs to the eboot.elf file and I dissassemble it like this:

~/.arduino15/packages/esp8266/tools/xtensa-lx106-elf-gcc/3.0.4-gcc10.3-1757bed/xtensa-lx106-elf/bin/objdump -d eboot.elf

Do you guys know why objdump is showing those curly brackets and why is it interpreting them like? Have I missunderstood part of the Xtensa manual? Am I maybe not running the right command?

Thank you very much!

Answer 1

xtensa assembler and disassembler use curly brackets for VLIW-style (usually called FLIX in xtensa world) instruction bundles: groups of opcodes decoded together as one instruction and executed by the processor in parallel. For example { l32r a15, 400e794c <__udivsi3+0xd9730>; excw } could be a two-slot instruction with l32r opcode in the first slot and excw opcode in the second. But if you see them in disassembly of code for xtensa cores that don't support FLIX (e.g. lx106 does not support FLIX) that usually means two things: 1) the disassembler is configured incorrectly and 2) it has likely lost the stream of instructions and is disassembling data or incorrectly composed instruction bytes.

In the example above one can see that instruction 4010f4af: bnez a2, 4010f4c0 <main+0x2c> jumps right into the middle of instruction 4010f4bf: excw. It means that there's a non-instruction byte at the address 0x4010f4bf, but the disassembler didn't realize that. Normally the disassembler uses the contents of the section .xt.prop to distinguish instruction bytes and non-instruction bytes and that helps it maintain synchronization with instruction stream, but when that section is missing it loses synchronization like that.

Regarding incorrect configuration: when binutils are built for a specific xtensa core one need to replace certain files in the binutils source with the contents of the xtensa configuration overlay generated for that core. It contains information about valid opcodes, instruction formats and their binary representation for that core and is used by the assembler and disassembler to only accept and produce valid instructions. The appearance of instruction formats that are not supported by the core in the disassembly is a clear sign of misconfiguration.

Excessive use of excw is yet another telltale sign of a bogus disassembly: because of the bug in the xtensa overlay generator (fixed somewhere between the releases RG-2017.5 and RG-2017.8 of xtensa tools) binutils disassembler reports the excw opcode instead of any unrecognized opcode when configured with an overlay produced by buggy tools.