[LLVMbugs] [Bug 15178] New: DWARF information for inlined functions is incorrect. Unable to break on inlined functions.

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=15178

            Bug ID: 15178
           Summary: DWARF information for inlined functions is incorrect.
                    Unable to break on inlined functions.
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jsweval at arxan.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 9969
  --> http://llvm.org/bugs/attachment.cgi?id=9969&action=edit
simple repro with inlined functions

It seems that the DWARF information that clang generates is faulty. The
attached example shows a function being inlined once. Running the executable
under gdb and setting a breakpoint for inlined_func correctly sees that there
is the original function and an inlined copy. However, gdb will not actually
break on the inlined version of the function when run. I'm guessing that the
address information is incorrect.

Steps to Repro:

1) Build clang+llvm (I used r174513 but I have seen this problem as far back as
3.2)
2) Build the attached example with `clang -o dwarf-inlining-test
dwarf-inlining-test.c -g -O3`
3) Run in gdb and try to set breakpoints

(gdb) b inlined_func
Breakpoint 1 at 0x100000e94: file dwarf-inlining-test.c, line 13.
Breakpoint 2 (inlined inlined_func) at 0x100000e90: file dwarf-inlining-test.c,
line 21.

// ok that looks good...

(gdb) b inline_in_here 
Breakpoint 3 at 0x100000ec4: file dwarf-inlining-test.c, line 17.
Note: breakpoint 1 also set at pc 0x100000e94.
Breakpoint 4 at 0x100000e94: file dwarf-inlining-test.c, line 13.
warning: Multiple breakpoints were set.
Use the "delete" command to delete unwanted breakpoints.

// uhoh... why does inline_in_here have multiple breakpoints? it is even marked
noinline!

(gdb) r
Starting program:
/Users/jsweval/code/llvm/bugs/dwarf-inlining/dwarf-inlining-test 
Reading symbols for shared libraries +............................. done

Breakpoint 3, 0x0000000100000ec4 in inline_in_here () at
dwarf-inlining-test.c:17
17    __attribute__((noinline)) void inline_in_here(void) {
(gdb) c
Continuing.
Current language:  auto; currently minimal

Program exited normally.
(gdb) 

// great, the breakpoints for inlined_func were never tripped!


Expected Behavior:
4) Build with gcc `gcc -o dwarf-inlining-test dwarf-inlining-test.c -g -O3`
5) Run the gcc version in gdb

(gdb) b inlined_func
Breakpoint 1 (inlined inlined_func) at 0x100000ea0: file dwarf-inlining-test.c,
line 12.
Breakpoint 2 at 0x100000e54: file dwarf-inlining-test.c, line 13.
warning: Multiple breakpoints were set.
Use the "delete" command to delete unwanted breakpoints.
(gdb) b inline_in_here 
Breakpoint 3 at 0x100000e84: file dwarf-inlining-test.c, line 20.
(gdb) r
Starting program:
/Users/jsweval/code/llvm/bugs/dwarf-inlining/dwarf-inlining-test 
Reading symbols for shared libraries +............................. done

Breakpoint 3, inline_in_here () at dwarf-inlining-test.c:20
20        for (i = 0; i < N; i++) {
(gdb) c
Continuing.

Breakpoint 1, inlined_func [inlined] () at
/Users/jsweval/code/llvm/bugs/dwarf-inlining/dwarf-inlining-test.c:12
12        // store the result and reset the state
(gdb) 

// works fine!

-- 
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/20130206/3b2bb585/attachment.html>