<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Great! Just know the debugger always uses exactly what the compiler gives us so using "dwarfdump --debug-line -e <dwarffile>" will always show you what the compiler is giving us. <div class=""><br class=""></div><div class="">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:<div class=""><br class=""></div><div class="">(lldb) command script import lldb/examples/python/lldbtk.py</div><div class="">(lldb) file a.out</div><div class="">(lldb) tk-target</div><div class=""><br class=""></div><div class="">Then expand as shown and you will see all line table entries.</div><div class=""><img apple-inline="yes" id="CBBC8603-E652-4CD7-A11A-66F9B8DEABB6" height="947" width="1082" apple-width="yes" apple-height="yes" src="cid:1DBF4F5D-64AE-448D-A743-38EC8D28FD2F@apple.com" class=""><br class=""><div class=""><blockquote type="cite" class="">On Oct 9, 2014, at 2:49 AM, Mario Zechner <<a href="mailto:badlogicgames@gmail.com" class="">badlogicgames@gmail.com</a>> wrote:<br class=""><br class="">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 <a href="http://pastebin.com/FM1BXJdX" class="">http://pastebin.com/FM1BXJdX</a> 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.<br class=""><br class="">Thanks for the help!<br class=""><br class="">On Thu, Oct 9, 2014 at 10:57 AM, Mario Zechner <badlogicgames@gmail.com> wrote:<br class="">Here's the dwarfdump: http://pastebin.com/4DyfLrtc<br class=""><br class="">That tells me that there aren't any addresses associated with the missing lines.<br class=""><br class="">They are in the LLVM IR http://pastebin.com/zBwtwPgh<br class=""><br class="">But they are missing from the generated assembler code: http://pastebin.com/t6fvTXZU<br class=""><br class="">My guess would be that we have some LLVM optimization turned on that eliminates the code for the missing lines. I'll investigate.<br class=""><br class="">Thanks a lot for your help, really appreciate it. Sorry if i wasted your time.<br class=""><br class="">On Wed, Oct 8, 2014 at 8:27 PM, Greg Clayton <gclayton@apple.com> wrote:<br class="">Please attach the output of "dwarfdump --debug-line -e <FILE>". I can tell you more when I see that output.<br class=""><br class="">Greg<br class=""><br class="">> On Oct 8, 2014, at 5:10 AM, Mario Zechner <badlogicgames@gmail.com> wrote:<br class="">><br class="">> Hi,<br class="">><br class="">> i'm currently trying to track down the following issue. We create LLVM IR like this<br class="">> compilation unit: JdwpThreads.java<br class="">> ; line 8<br class="">> %t16 = load %Object** %$r6, !dbg !{i32 8, i32 0, metadata !33, null}<br class="">> store %Object* %t16, %Object** %r4, !dbg !{i32 8, i32 0, metadata !33, null}<br class="">><br class="">> ; line 19<br class="">> call void @"llvm.dbg.declare"(metadata !{%Object** %r4}, metadata !38), !dbg !{i32 19, i32 0, metadata !34, null}<br class="">> %t17 = load %Object** %r4, !dbg !{i32 19, i32 0, metadata !34, null}<br class="">> 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}<br class="">><br class="">> ; line 20<br class="">> %t18 = trunc i32 0 to i8, !dbg !{i32 20, i32 0, metadata !34, null}<br class="">> call void @"[j]com.robovm.debug.server.apps.JdwpThreads.stopped(Z)[set]"(%Env* %p0, i8 %t18), !dbg !{i32 20, i32 0, metadata !34, null}<br class="">><br class="">> ; line 21<br class="">> %t19 = load %Object** %r4, !dbg !{i32 21, i32 0, metadata !34, null}<br class="">> 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}<br class="">><br class="">> When setting a breakpoint for line 19 or 20 in that compilation unit, LLDB resolves it to line 21<br class="">><br class="">> (lldb) br set -f JdwpThreads.java -l 19<br class="">><br class="">> Breakpoint 1: where = JdwpThreadTest`[J]com.robovm.debug.server.apps.JdwpThreads.main([Ljava/lang/String;)V + 282 at JdwpThreads.java:21, address = 0x0028531f<br class="">><br class="">> (lldb) br set -f JdwpThreads.java -l 20<br class="">><br class="">> Breakpoint 2: where = JdwpThreadTest`[J]com.robovm.debug.server.apps.JdwpThreads.main([Ljava/lang/String;)V + 282 at JdwpThreads.java:21, address = 0x0028531f<br class="">><br class="">><br class="">> The functions being called are all inlined functions. I suspected that to be the issue but don't know how to resolve it.<br class="">><br class="">> 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.<br class="">><br class="">> Thanks,<br class="">> Mario<br class="">> _______________________________________________<br class="">> lldb-dev mailing list<br class="">> lldb-dev@cs.uiuc.edu<br class="">> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev<br class=""><br class=""><br class=""><br class=""></blockquote><br class=""></div></div></div></body></html>