[llvm-bugs] [Bug 37391] New: [DebugInfo] Bug in location list address ranges for conditional instruction

[via llvm-bugs]

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

            Bug ID: 37391
           Summary: [DebugInfo] Bug in location list address ranges for
                    conditional instruction
           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

Hello,

This follows the discussion in
http://lists.llvm.org/pipermail/llvm-dev/2018-May/123080.html

Consider this function:
int verifyPIN(char *userPin, char *cardPin, int *cpt)
{
  int i;
  int status;
  int diff;

  if (*cpt > 0) {
    status = 0x55;
    diff = 0x55;

    for (i = 0; i < 4; i++) {
      if (userPin[i] != cardPin[i]) {
        diff = 0xAA;
      }
    }

    if (diff == 0x55) {
      status = 0xAA;
    }
    else {
      status = 0x55;
    }

    if (status == 0xAA) {
      *cpt = 3;
      return 0xAA;
    } else {
      *cpt--;
      return 0x55;
    }
  }

  return 0x55;
}

Compiling it using:

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

Here's the assembly code of `verifyPin()`:
00008124 <verifyPin>:
    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 <verifyPin+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 <verifyPin+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

Here's the debug location of `userPin`:
 <2><3b>: Abbrev Number: 3 (DW_TAG_formal_parameter)
    <3c>   DW_AT_location    : 0x0 (location list)
    <40>   DW_AT_name        : (indirect string, offset: 0x9e): userPin
    <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>

So, currently, r4 contains `userPin`'s value until 0x8134 (poplt {r4, r6, r7,
pc}). However, this is only correct when cpt <= 0 (so 812e: cmp r0, #1 yields
`lt`).

This is because in `IfConversionPass`, `poplt` is generated and is considered
to clobber r4. There's no logic to handle conditional instruction in subsequent
passes, so `DbgValueHistoryCalculator` closes the range at 0x8134.

I think the solution is that conditional instructions should not clobber
register. What do you think?

Thanks for the help

-- 
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/20180509/8537ad03/attachment.html>