Line number resolution problem

Subprojects LLDB
1

Hi,

i’m currently trying to track down the following issue. We create LLVM IR like this
compilation unit: JdwpThreads.java
; line 8

%t16 = load %Object** %$r6, !dbg !{i32 8, i32 0, metadata !33, null}
store %Object* %t16, %Object** %r4, !dbg !{i32 8, i32 0, metadata !33, null}

; line 19
call void @“llvm.dbg.declare”(metadata !{%Object** %r4}, metadata !38), !dbg !{i32 19, i32 0, metadata !34, null}
%t17 = load %Object** %r4, !dbg !{i32 19, i32 0, metadata !34, null}
call void @“[j]java.lang.Thread.start()V[Invokevirtual(com/robovm/debug/server/apps/JdwpThreads,java/lang/Thread)]”(%Env* %p0, %Object* %t17), !dbg !{i32 19, i32 0, metadata !34, null}

; line 20
%t18 = trunc i32 0 to i8, !dbg !{i32 20, i32 0, metadata !34, null}
call void @“[j]com.robovm.debug.server.apps.JdwpThreads.stopped(Z)[set]”(%Env* %p0, i8 %t18), !dbg !{i32 20, i32 0, metadata !34, null}

; line 21
%t19 = load %Object** %r4, !dbg !{i32 21, i32 0, metadata !34, null}
call void @“[j]java.lang.Thread.join()V[Invokevirtual(com/robovm/debug/server/apps/JdwpThreads,java/lang/Thread)]”(%Env* %p0, %Object* %t19), !dbg !{i32 21, i32 0, metadata !34, null}

When setting a breakpoint for line 19 or 20 in that compilation unit, LLDB resolves it to line 21

(lldb) br set -f JdwpThreads.java -l 19

Breakpoint 1: where = JdwpThreadTest`[J]com.robovm.debug.server.apps.JdwpThreads.main([Ljava/lang/String;)V + 282 at JdwpThreads.java:21, address = 0x0028531f

(lldb) br set -f JdwpThreads.java -l 20

Breakpoint 2: where = JdwpThreadTest`[J]com.robovm.debug.server.apps.JdwpThreads.main([Ljava/lang/String;)V + 282 at JdwpThreads.java:21, address = 0x0028531f

The functions being called are all inlined functions. I suspected that to be the issue but don’t know how to resolve it.

I’m a bit puzzled as to why that is and would appreciate any pointers. I can provide a Mac OS X binary or a dwarfdump if required.

Thanks,
Mario

2

Please attach the output of "dwarfdump --debug-line -e <FILE>". I can tell you more when I see that output.

Greg

3

Here’s the dwarfdump: http://pastebin.com/4DyfLrtc

That tells me that there aren’t any addresses associated with the missing lines.

They are in the LLVM IR http://pastebin.com/zBwtwPgh

But they are missing from the generated assembler code: http://pastebin.com/t6fvTXZU

My guess would be that we have some LLVM optimization turned on that eliminates the code for the missing lines. I’ll investigate.

Thanks a lot for your help, really appreciate it. Sorry if i wasted your time.

4

Following up on this, the issue seems to be with LLVM’s alwaysinline pass, which is the only pass we activate when compiling in debug mode. This LLVM IR http://pastebin.com/FM1BXJdX gets turned into this http://pastebin.com/g1Nv8PJL assembler code, with and without the pass. Turning off that pass can resolve the issue in terms of emitting the proper debug info in the assembler code.

Thanks for the help!

5

Great! Just know the debugger always uses exactly what the compiler gives us so using “dwarfdump --debug-line -e ” will always show you what the compiler is giving us.

You can also inspect your target to see the line tables with the new “tk” support. LLDB top of tree has a script “lldb/examples/python/lldbtk.py” that adds a bunch of “tk” prefixed commands including “tk-target” to inspect your target:

(lldb) command script import lldb/examples/python/lldbtk.py
(lldb) file a.out
(lldb) tk-target

Then expand as shown and you will see all line table entries.

Screen Shot 2014-10-09 at 10.35.43 AM.png
Screen Shot 2014-10-09 at 10.35.43 AM.png1082×947 181 KB

6

It just didn’t occur to me that the inliner pass would kill line location info in the resulting assembler output. Should spend more time learning my tools of choice. lldbtk will come in handy! More reason to synch with the latest and greatest.

Thanks!

7

The lldbtk.py actually works with older LLDB's, you just need the file and it will work with many older versions.