What's the compiler bug? I see a DW_AT_subprogram entry for main_gdbserver, and linetable entries for the addresses of main_gdbserver.
I've found that getting DWARF compiler bugs fixed can be...challenging. The better I can narrow it down for the compiler engineers, the better. This is clang that was ToT about 2 months ago, BTW. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project > -----Original Message----- > From: Greg Clayton [mailto:gclay...@apple.com] > Sent: Monday, October 17, 2016 11:03 AM > To: Ted Woodward <ted.woodw...@codeaurora.org> > Cc: LLDB <lldb-dev@lists.llvm.org> > Subject: Re: [lldb-dev] LLDB can't find source...but it can? > > This is a compiler bug. > > > On Oct 14, 2016, at 12:14 PM, Ted Woodward > <ted.woodw...@codeaurora.org> wrote: > > > >> Probably a debug info problem. Before we know to look for addresses > >> within a compile unit, the compile unit must claim it has a function > >> that contains this address. So check the DWARF in the compile unit > >> that contains 0x114720 (not sure if there is a lookup by address in > >> llmv-dwarfdump?) and make sure there is a DW_TAG_subprogram that > contains this address. > >> > >> Greg > > > > I'm changing gears here - I'm having the same issue with lldb-server, and > it's smaller, so I'm looking at that. > > > > main calls main_gdbserver, which is in tools/lldb-server/lldb- > gdbserver.cpp, and has no line table info, according to lldb's list comm info. > > > > 4: name = 'main_gdbserver', locations = 2 > > 4.1: where = lldb-server`main_gdbserver(int, char**) + 32, address = > > 0x00048964, unresolved, hit count = 0 > > 4.2: where = lldb-server`main_gdbserver(int, char**) + 32, address = > > 0x00048964, unresolved, hit count = 0 > > > > (lldb) list 0x48964 > > error: address resolves to lldb-server[0x0000000000048964], but there is no > line table information available for this address. > > > > > > main_gdbserver has a DW_AT_subprogram entry: > > 0x000306a4: DW_TAG_subprogram [106] * > > DW_AT_low_pc [DW_FORM_addr] (0x0000000000048944) > > DW_AT_high_pc [DW_FORM_data4] (0x00000da4) > > DW_AT_frame_base [DW_FORM_exprloc] (<0x1> 6e ) > > DW_AT_linkage_name [DW_FORM_strp] ( > .debug_str[0x0006577b] = "_Z14main_gdbserveriPPc") > > DW_AT_name [DW_FORM_strp] ( .debug_str[0x00065792] = > "main_gdbserver") > > DW_AT_decl_file [DW_FORM_data1] > ("/local/mnt/workspace/ted/linux/llvm/tools/lldb/tools/lldb- > server/lldb-gdbserver.cpp") > > DW_AT_decl_line [DW_FORM_data2] (326) > > DW_AT_type [DW_FORM_ref4] (cu + 0x003b => {0x00011c13}) > > DW_AT_external [DW_FORM_flag_present] (true) > > > > And a linetable entry: > > 0x0000000000048944 327 0 1 0 0 is_stmt > > 0x0000000000048964 328 11 1 0 0 is_stmt > > prologue_end > > > > > > > > -- > > Qualcomm Innovation Center, Inc. > > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > > a Linux Foundation Collaborative Project > > > >> -----Original Message----- > >> From: Greg Clayton [mailto:gclay...@apple.com] > >> Sent: Tuesday, October 11, 2016 1:34 PM > >> To: Ted Woodward <ted.woodw...@codeaurora.org> > >> Cc: LLDB <lldb-dev@lists.llvm.org> > >> Subject: Re: [lldb-dev] LLDB can't find source...but it can? > >> > >> > >>> On Oct 7, 2016, at 4:53 PM, Ted Woodward via lldb-dev <lldb- > >> d...@lists.llvm.org> wrote: > >>> > >>> Background – I’m working on getting LLDB to run on Hexagon Linux, > >>> built > >> with an LLVM toolchain. We’re using libc++ and MUSL. The loader is a > >> bit squirrelly right now, so I’ve built LLDB statically. > >>> > >>> I’ve got full source debugging in the driver, but when I step into > >> SBDebugger::Create, I don’t have any source. I’ve got symbols: > >>> (lldb) bt > >>> * thread #1: tid = 1, 0x00114730 lldb`lldb::SBDebugger::Create(bool) > >>> + 16, > >> stop reason = breakpoint 2.1 > >>> * frame #0: 0x00114730 lldb`lldb::SBDebugger::Create(bool) + 16 > >>> frame #1: 0x000001dc lldb`Driver::Driver(this=0x7ffefc50) + 124 > >>> at > >> Driver.cpp:150 > >>> frame #2: 0x00006aa0 lldb`main(argc=1, argv=0x7ffefd34) + 240 at > >> Driver.cpp:1350 > >>> frame #3: 0x04744384 lldb`__libc_start_main + 48 > >>> > >>> list SBDebugger::Create fails, but list SBDebugger::Create(bool) > >>> gives me > >> source. > >>> (lldb) list SBDebugger::Create > >>> (lldb) list SBDebugger::Create(bool) > >>> File: > >> > \local\mnt\workspace\ted\linux\llvm\tools\lldb\source\API\SBDebugger. > >> cp > >> p > >>> 172 return SBDebugger::Create(false, nullptr, nullptr); > >>> 173 } > >>> 174 > >>> 175 SBDebugger > >>> 176 SBDebugger::Create(bool source_init_files) > >>> 177 { > >>> 178 return SBDebugger::Create (source_init_files, nullptr, > >>> nullptr); > >>> 179 } > >>> 180 > >>> 181 SBDebugger > >>> 182 SBDebugger::Create(bool source_init_files, > >>> lldb::LogOutputCallback > >> callback, void *baton) > >>> 183 > >>> > >>> Finally, I try to list based on the address of the function: > >>> (lldb) list 0x114720 > >>> error: address resolves to lldb[0x0000000000114720], but there is no > >>> line > >> table information available for this address. > >>> > >>> But there is line table information for 0x114720 (from llvm-dwarfdump): > >>> 0x0000000000114720 177 0 80 0 0 is_stmt > >>> 0x0000000000114730 178 32 80 0 0 is_stmt > >>> prologue_end > >>> 0x0000000000114734 178 12 80 0 0 > >>> 0x0000000000114754 178 5 80 0 0 > >>> > >>> > >>> > >>> My breakpoint at SBDebugger::Create resolved to prologue_end: > >>> (lldb) break list > >>> Current breakpoints: > >>> 1: name = 'main', locations = 1, resolved = 1, hit count = 1 > >>> 1.1: where = lldb`main + 32 at Driver.cpp:1335, address = > >>> 0x000069d0, > >> resolved, hit count = 1 > >>> > >>> 2: name = 'SBDebugger::Create', locations = 3, resolved = 3, hit > >>> count = 1 > >>> 2.1: where = lldb`lldb::SBDebugger::Create(bool) + 16, address = > >> 0x00114730, resolved, hit count = 1 > >>> 2.2: where = lldb`lldb::SBDebugger::Create() + 8, address = > >>> 0x001143c0, > >> resolved, hit count = 0 > >>> 2.3: where = lldb`lldb::SBDebugger::Create(bool, void (*)(char > >>> const*, > >> void*), void*) + 40, address = 0x00114404, resolved, hit count = 0 > >>> > >>> > >>> So – why can LLDB find the source when I specify the function > >>> explicitly, or > >> find the line table info when I set a breakpoint, but not when I am > >> in the function or list an address? > >>> > >> > >> > >>> Ted > >>> > >>> -- > >>> Qualcomm Innovation Center, Inc. > >>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora > >>> Forum, > >> a Linux Foundation Collaborative Project > >>> > >>> _______________________________________________ > >>> lldb-dev mailing list > >>> lldb-dev@lists.llvm.org > >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
