Line-based breakpoints in inline functions don't show correct source

[jdm]

#[inline(always)]
fn bar() -> int {
    5
}

fn main() {
    let _ = bar();
}

(gdb) break inline.rs:3
Breakpoint 1 at 0x404e80: file inline.rs, line 3.
(gdb) r
Starting program: /tmp/inline 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, inline::main () at inline.rs:6
6   fn main() {
(gdb) 

[michaelwoerister]

Taking some notes here:

• What should actually be shown here is line 3
• Take a look at the DWARF line tables to see what machine code is associated with what source code.
• Verify that source positions are created correctly for the inlined function in the IR.
• Check whether this only occurs with trivial inlined functions like this with longer ones (e.g. containing a function call) too.

[michaelwoerister]

Interesting, the unoptimized IR of the above program does not even contain a function bar()...

; Function Attrs: uwtable
define internal void @_ZN4main20h4bedfa0b9eaa7039jaaE() unnamed_addr #0 {
entry-block:
  %0 = alloca i32
  %let = alloca i32
  store i32 5, i32* %0, !dbg !18 ; <=== no function call 
  %1 = load i32* %0, !dbg !18
  store i32 %1, i32* %let
  ret void, !dbg !20
}

[jdm]

Maybe inline(always) is serious about inlining?

[michaelwoerister]

Yeah, I need to find out where this inlining happens. Do we do it? Does LLVM do it?

[dotdash]

Try looking at the .0.noopt.bc file produced by -C save-temps instead
Am 05.03.2015 16:17 schrieb "Josh Matthews" [email protected]:

Maybe inline(always) is serious about inlining?

—
Reply to this email directly or view it on GitHub
#13442 (comment).

[michaelwoerister]

@dotdash Good tip!

; Function Attrs: alwaysinline uwtable
define internal i64 @_ZN3bar20h4b0789288b21a387eaaE() unnamed_addr #0 {
entry-block:
  ret i64 5, !dbg !19
}

; Function Attrs: uwtable
define internal void @_ZN4main20h0007eb42fb7e75b0jaaE() unnamed_addr #1 {
entry-block:
  %0 = alloca i64
  %let = alloca i64
  %1 = call i64 @_ZN3bar20h4b0789288b21a387eaaE(), !dbg !20
  store i64 %1, i64* %0, !dbg !20
  %2 = load i64* %0, !dbg !20
  store i64 %2, i64* %let
  ret void, !dbg !22
}
...
!19 = !MDLocation(line: 4, scope: !4)
!20 = !MDLocation(line: 7, scope: !21)

This one contains the function but the return statement is described as being on line 4 instead of line 3. That's definitely wrong.
Making it an actual return statement fixes that, kind of:

; Function Attrs: alwaysinline uwtable
define internal i64 @_ZN3bar20he4086b460583a695eaaE() unnamed_addr #0 {
entry-block:
  br label %return, !dbg !19

return:                                           ; preds = %entry-block
  ret i64 5, !dbg !21
}
...
!19 = !MDLocation(line: 3, scope: !20)
!21 = !MDLocation(line: 4, scope: !4)

The outcome is still wrong though.

[brson]

Nominating to prioritize.

[nikomatsakis]

triage: P-medium

[pnkfelix]

@michaelwoerister FYI this still seems to reproduce today, I think.

[Mark-Simulacrum]

Appears to still reproduce today.

(gdb) break test.rs:3
Breakpoint 1 at 0x8924: file test.rs, line 3.
(gdb) r
Starting program: test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, test::main () at test.rs:7
7	    let _ = bar();

[myrfy001]

it seems that still can't set breakpoint in inlined functions now

[jdm]

I believe this issue was closed incorrectly. 7741e3d does not appear to have anything to do with it.

[michaelwoerister]

Indeed!