LLDB can't find source...but it can?

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.cpp

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

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.cpp
   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?

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

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

This is a compiler bug.

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.

Send me the file offline. I will help narrow it down for you.