[lldb-dev] Regenerating public API reference documentation

[Tamas Berghammer via lldb-dev]

Hi All,

The current LLDB API reference documentation available at
http://lldb.llvm.org/python_reference/
 and at
http://lldb.llvm.org/cpp_reference/html/ but it haven't been updated since
July 2013.

I am planning to regenerate it next week using "ninja lldb-cpp-doc
lldb-python-doc" (from a Linux machine using epydoc 3.0.1 and doxygen
1.8.6) to get them up to date. Is there any objection against it?

Additionally, in the future it would be great if we can keep the generated
doc more up to date after additions to the SB API so users of LLDB can rely
it.

Tamas
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Regenerating public API reference documentation

[Mehdi Amini via lldb-dev]

> On Oct 14, 2016, at 6:44 AM, Tamas Berghammer via lldb-dev 
>  wrote:
> 
> Hi All,
> 
> The current LLDB API reference documentation available at 
> http://lldb.llvm.org/python_reference/ 
>  and at 
> http://lldb.llvm.org/cpp_reference/html/ 
>  but it haven't been updated since 
> July 2013.
> 
> I am planning to regenerate it next week using "ninja lldb-cpp-doc 
> lldb-python-doc" (from a Linux machine using epydoc 3.0.1 and doxygen 1.8.6) 
> to get them up to date. Is there any objection against it?
> 
> Additionally, in the future it would be great if we can keep the generated 
> doc more up to date after additions to the SB API so users of LLDB can rely 
> it.

There is a bot continuously updating http://llvm.org/docs/ 
 ; ideally we should be able to hook the other LLVM 
sub-projects there.

— 
Mehdi___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB can't find source...but it can?

[Ted Woodward via lldb-dev]

> 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[0x00048964], 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] (0x00048944)
DW_AT_high_pc [DW_FORM_data4]   (0x0da4)
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:
0x00048944327  0  1   0 0  is_stmt
0x0004896432811  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 
> Cc: LLDB 
> 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  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: 0x01dc lldb`Driver::Driver(this=0x7ffefc50) + 124 at
> Driver.cpp:150
> > frame #2: 0x6aa0 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[0x00114720], but there is no line
> table information available for this address.
> >
> > But there is line table information for 0x114720 (from llvm-dwarfdump):
> > 0x00114720177  0 80   0 0  is_stmt
> > 0x00114730178 32 80   0 0  is_stmt 
> > prologue_end
> > 0x00114734178 12 80   0 0
> > 0x00114754178  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 = 0x69d0,
> resolved, hit count = 1
> >
> > 2: name = 'SBDebugger::Create', locations = 3, resolved = 3, hit count = 1
> >   2.1: where = lldb`lldb::SBDebugger::Create(bool) + 16, addres