Dwarf debugging information lost


Below is a snippet of binary codes and the binary is compiled by clang with flag gdwarf-3. It is easy to see that 0x912c is an indirect jump and instruction 0x9128 and 0x912c would be together as a basic block

.text:0000911C loc_911C ; CODE XREF: main+7F4 j

.text:0000911C SUB R0, R0, #1
.text:00009120 CMP R0, #3 ; switch 4 cases
.text:00009124 BHI loc_9218 ; jumptable 0000912C default case
.text:00009128 ADR R1, off_9130
.text:0000912C LDR PC, [R1,R0,LSL#2] ; switch jump

.text:00009130 off_9130 DCD loc_9778 ; DATA XREF: main+818 o
.text:00009130 DCD loc_9108 ; jump table for switch statement
.text:00009130 DCD loc_9778
.text:00009130 DCD loc_9140

I use llvm-dwarfdump -debug-line to dump the debug information. However, I find the related output below.0x912c is not described while the line of 0x9128 is zero, which does not help.

542 0x0000000000009108 0 0 3 0 0
543 0x000000000000911c 474 4 3 0 0
544 0x0000000000009128 0 4 3 0 0
545 0x0000000000009140 511 45 3 0 0 is_stmt

I find nearly all the instructions that are indirect jumps would not be described by the dwarf debugging information. Anyone know the reason? Any comments or suggestions are welcome. Many Thanks


Hi Muhui,

It is quite likely that the indirect branch instruction (at IR or MIR level) was created without an explicit source location, and because it is its own basic block, it was given line 0 when the object code was emitted. I suspect some pass didn’t really consider that the indirect branch would be treated as its own basic block, and simply didn’t bother to add a source location when it should have. Naively it should have the same source location as the conditional branch.

Offhand I don’t know where the decision to use a jump table is made, but once you find the pass that introduces this pattern it should be fairly easy to see how to fix it.