[llvm-bugs] [Bug 37149] New: [DebugInfo] Wrong start address in location list ranges

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=37149

            Bug ID: 37149
           Summary: [DebugInfo] Wrong start address in location list
                    ranges
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: sontuan.vu119 at gmail.com
                CC: llvm-bugs at lists.llvm.org

Consider this C function:

void masked_aes(uint8_t plain_text[16], uint8_t key[16], uint8_t
ciphered_text[16])

Compiling it using:

$ clang -c -target arm-none-eabi -mcpu=cortex-m3 -mthumb -O1 -g aes.c -o aes.o
$ arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb -o aes aes.o

Then using objdump to inspect the DWARF information in the binary:

$ arm-none-eabi-objdump -DWiol aes > debug.obj

Here's the DIEs for those 3 parameters:

<2><43e>: Abbrev Number: 10 (DW_TAG_formal_parameter)            
  <43f>   DW_AT_location    : 0x34e (location list)             
  <443>   DW_AT_name        : (indirect string, offset: 0xd8): plain_text

<2><44d>: Abbrev Number: 10 (DW_TAG_formal_parameter)            
  <44e>   DW_AT_location    : 0x377 (location list)             
  <452>   DW_AT_name        : (indirect string, offset: 0xba): key

<2><45c>: Abbrev Number: 10 (DW_TAG_formal_parameter)            
  <45d>   DW_AT_location    : 0x396 (location list)             
  <461>   DW_AT_name        : (indirect string, offset: 0x151): ciphered_text

And their corresponding location lists:

 // plain_text
 0000034e 0000850e 0000851a (DW_OP_reg0 (r0))
 00000359 0000851a 000085c0 (DW_OP_reg5 (r5))
 00000364 000085c8 000085da (DW_OP_reg5 (r5))
 0000036f <End of list>

 // key
 00000377 0000850e 0000851a (DW_OP_reg1 (r1))
 00000382 0000851a 00008676 (DW_OP_breg13 (r13): 8)
 0000038e <End of list>

 // ciphered_text
 00000396 0000850e 0000851a (DW_OP_reg2 (r2))
 000003a1 0000851a 0000851e (DW_OP_reg9 (r9))
 000003ac <End of list>

Here's part of the assembly code of "masked_aes()":

 0000850e <masked_aes>:
     850e:   b5f0        push    {r4, r5, r6, r7, lr}
     8510:   af03        add r7, sp, #12
     8512:   e92d 0f00   stmdb   sp!, {r8, r9, sl, fp}
     8516:   b0f5        sub sp, #468    ; 0x1d4
     8518:   4605        mov r5, r0
     851a:   2007        movs    r0, #7
     851c:   4691        mov r9, r2
     851e:   9102        str r1, [sp, #8]
     8520:   f000 f938   bl  8794 <srand>
     ...

The location of "plain_text" is correct, but it is not the case for the other 2
parameters.  For example, if we take a closer look at "key", we can see that
the first location range should end at address 0x8520 instead of 0x851a, while
the second location range should start at address 0x851e instead of 0x851a. 
Likewise, we should fix the location range addresses of "ciphered_text".

Digging a bit further into this, I have found that the problem lies in
"lib/CodeGen/LiveDebugVariables.cpp".  In "UserValue::emitDebugValues()", we
have something like:

     if (trimmedDefs.count(Start))
       Start = Start.getPrevIndex();

However, "getPrevIndex()" does not give us a precise location.  I mean, it
returns the same instruction index for all 3 DBG_VALUES corresponding to 3
different variables ("plain_text", "key" and "ciphered_text").  One fix that I
can think of is to save the instruction index for *each* DBG_VALUE in
"UserValue::computeIntervals()", where "trimmedDefs" is built, so that we can
retrieve the correct instruction index in "UserValue::emitDebugValues()"
instead of using "getPrevIndex()".

This is the first time I report a bug in LLVM, not sure if this is the way to
do and if I explain things clearly enough, but I'm looking forward for your
feedback on this.

Thank you all,

Son Tuan Vu

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180417/5f94d0e8/attachment-0001.html>