Support xc16 (pic) disassembler output
sarfata opened this issue · comments
The disassembly generated by the xc16 toolchain (microchip) generates symbols for every label in the source code. For example, this is one function that gets transformed into multiple symbols: SetUsbChannel
, .L3
, .L4
, .L6
, .L2
.
00007270 <_SetUsbChannel>:
SetUsbChannel():
/project/bootload.X/usb_switch.c:21
7270: 88 1f 78 mov.w w8, [w15++]
7272: 00 04 78 mov.w w0, w8
/project/bootload.X/usb_switch.c:25
7274: e1 0f 54 sub.w w8, #0x1, [w15]
7276: 09 00 32 bra Z, 0x728a <.L4>
7278: 03 00 39 bra NC, 0x7280 <.L3>
727a: e2 0f 54 sub.w w8, #0x2, [w15]
727c: 0f 00 3a bra NZ, 0x729c <.L2>
727e: 0a 00 37 bra 0x7294 <.L6>
00007280 <.L3>:
/project/bootload.X/usb_switch.c:28
7280: e0 00 20 mov.w #0xe, w0
7282: a0 ff 07 rcall 0x71c4 <_output_high> <.LFB8> <.LFE7>
/project/bootload.X/usb_switch.c:29
7284: f0 00 20 mov.w #0xf, w0
7286: a8 ff 07 rcall 0x71d8 <_output_low> <.LFB9> <.LFE8>
/project/bootload.X/usb_switch.c:30
7288: 09 00 37 bra 0x729c <.L2>
0000728a <.L4>:
/project/bootload.X/usb_switch.c:33
728a: e0 00 20 mov.w #0xe, w0
728c: a5 ff 07 rcall 0x71d8 <_output_low> <.LFB9> <.LFE8>
/project/bootload.X/usb_switch.c:34
728e: f0 00 20 mov.w #0xf, w0
7290: a3 ff 07 rcall 0x71d8 <_output_low> <.LFB9> <.LFE8>
/project/bootload.X/usb_switch.c:35
7292: 04 00 37 bra 0x729c <.L2>
00007294 <.L6>:
/project/bootload.X/usb_switch.c:38
7294: e0 00 20 mov.w #0xe, w0
7296: a0 ff 07 rcall 0x71d8 <_output_low> <.LFB9> <.LFE8>
/project/bootload.X/usb_switch.c:39
7298: f0 00 20 mov.w #0xf, w0
729a: 94 ff 07 rcall 0x71c4 <_output_high> <.LFB8> <.LFE7>
0000729c <.L2>:
/project/bootload.X/usb_switch.c:43
729c: 78 43 88 mov.w w8, 0x86e
/project/bootload.X/usb_switch.c:44
729e: 4f 04 78 mov.w [--w15], w8
72a0: 00 00 06 return
The current result is that for a elf file disassembled with this toolset, 80% of the code size goes in <unknown>/<unknown>
and looking at SetUsbChannel
only shows the first few lines of the assembly. Callers/Callees counting is also broken (related to #7/#8/#20 probably).
Todo:
- add some tests parsing this type of output
- parse assembly all the way til the end of the function (until beginning of the next one is probably the only way to detect the end of one)
- figure out a way to sum the size of all the symbols that make one function