[llvm-dev] [DbgInfo] Potential bug in location list address ranges

Son Tuan VU via llvm-dev llvm-dev at lists.llvm.org
Fri Apr 27 07:48:17 PDT 2018


Hi all,

Consider this ARM assembly code of a C function:

00008124 <foo>:
    8124:                   push    {r4, r6, r7, lr}
    8126:                   add     r7, sp, #8
    8128:                   mov     r4, r0
    812a:                   ldrsb.w r0, [r2]
    812e:                   cmp     r0, #1
    8130:                   itt     lt
    8132:                   movlt   r0, #85 ; 0x55
    8134:                   poplt   {r4, r6, r7, pc}            // a
function return

    8136:                   ldrb.w  ip, [r1, #3]
    813a:                   ldrb.w  lr, [r4, #3]
    813e:                   movs    r0, #85 ; 0x55
    8140:                   cmp     lr, ip
    8142:                   bne.n   8168 <foo+0x44>

    8144:                   ldrb.w  ip, [r1, #2]
    8148:                   ldrb    r3, [r4, #2]
    814a:                   cmp     r3, ip
    814c:                   it      ne
    814e:                   popne   {r4, r6, r7, pc}          // a function
return

    8150:                   ldrb.w  ip, [r1, #1]
    8154:                   ldrb    r3, [r4, #1]
    8156:                   cmp     r3, ip
    8158:                   bne.n   8168 <foo+0x44>

    815a:                   ldrb    r1, [r1, #0]
    815c:                   ldrb    r3, [r4, #0]
    815e:                   cmp     r3, r1
    8160:                   ittt    eq
    8162:                   moveq   r0, #3
    8164:                   strbeq  r0, [r2, #0]
    8166:                   moveq   r0, #170        ; 0xaa
    8168:                   pop     {r4, r6, r7, pc}          // a function
return

I have a variable *bar* and here's its corresponding DWARF DIE:

 <2><3b>: Abbrev Number: 3 (DW_TAG_formal_parameter)
    <3c>   DW_AT_location    : 0x0 (location list)
    <40>   DW_AT_name        : (indirect string, offset: 0x9e): *bar*
    <44>   DW_AT_decl_file   : 1
    <45>   DW_AT_decl_line   : 34
    <46>   DW_AT_type        : <0x153>

 // *Its location list*
    00000000 00008124 0000812a (DW_OP_reg0 (r0))
    0000000b 0000812a 00008136 (DW_OP_reg4 (r4))
    00000016 <End of list>

As you can see, it says that we can find *bar *in *r4* from *0x812a* to *0x8134
(poplt)*.  However, this is only true when the *cmp *instruction at
*0x812e* yields
*less than (lt)*.  So if the value in *r0 *is greater than 1 (which is the
case of my input), we should still be able to read the value of *bar* from
*r4* in the remaining of the function.

I don't know if we can consider this a bug, because I don't even know what
should be the correct location information for *bar*. However, in this
case, since the conditional instruction that clobbers *r4* is a function
return, I'd expect to read the value of *bar* from *r4* in the remaining of
the function.

If the conditional instruction *poplt *was *addlt r4, r0, 3* for example,
what should be the correct location list of *bar*?

For now, my only idea is to check if the clobbering MI is a *conditional
return* in *DbgValueHistoryCalculator* which computes the end address of a
location llist entry. But I do not feel like this is the correct fix though.

Looking forward to hearing your thoughts on this,

Thank you for reading this,

Son Tuan Vu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180427/a74dc47f/attachment-0001.html>


More information about the llvm-dev mailing list