> On Oct 7, 2016, at 4:53 PM, Ted Woodward via lldb-dev
> <lldb-dev@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.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
> 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
