Re: [lldb-dev] gdb-remote protocol questions

2020-01-27 Thread Alexander Zhang via lldb-dev 
Hi,

Thanks for pointing me towards stack unwinding. I don't have debug
information much of the time, so I'm depending on the architecture rules
for backtracing. A look at the mips ABI plugin shows it uses dwarf register
numbers to get the register values it needs, and I wasn't including them in
my qRegisterInfo responses. After fixing this, step over and step out
appear to work correctly, which is a great help.

However, backtraces only show 2 frames with the current pc and ra values,
no matter where I am, so it seems there's some problem getting stack frame
info from the actual stack. I've attached an unwind log from running bt
inside a function that should have a deeper backtrace. The afa value of
0x looks suspicious to me, but I don't really understand
where it comes from. The frame before 0x8002ee70 should, I think, be
0x80026a6c, as that's the pc after stepping out twice.

Thanks,
Alexander

On Sun, Jan 26, 2020 at 4:21 PM Jason Molenda  wrote:

> I suspect your problem may be related to lldb not knowing how to walk the
> stack on this target.  Is  mips-unknown-linux-gnu correct?  What do you see
> if you turn on unwind logging, 'log enable lldb unwind'.  You can also have
> lldb show you the unwind rules at the current pc value with 'image
> show-unwind -a $pc'.  I don't know what unwinders we have defined for this
> target in lldb right now -- if you have eh_frame information in your
> binary, lldb should read & use that.  Otherwise, if you have an assembly
> instruction profiler in lldb for mips, and start addresses for your
> functions, lldb should be able to inspect the instruction stream and figure
> out how to unwind out of the function correctly.  As a last resort, it will
> fall back to architecture rules for how to backtrace out of a function
> (defined in the ABI plugin) but those are often incorrect in
> prologue/epilogues (start & end of a function).
>
>
>
> (btw if you support no-ack mode, there's a lot less packet traffic between
> your stub and lldb - recommended.)
>
>
> J
>
>
>
>
> > On Jan 25, 2020, at 3:08 PM, Alexander Zhang via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi,
> >
> > I've been implementing a basic RSP protocol server for remotely
> debugging a MIPS simulator, and have been having some trouble getting
> certain lldb features to work there, in particular backtraces (bt) and
> instruction step over (ni). Does someone know what packets these commands
> rely on to work? I've attached some communication logs, and if it helps my
> code is at
> https://github.com/CQCumbers/nmulator/blob/master/src/debugger.h
> >
> > Please forgive me if this isn't the right place to ask - I know this
> isn't directly part of lldb development but I've tried several other places
> and haven't been able to find anyone familiar with the subject.
> >
> > Also, just a user question, but is there a way to show register values
> in hex format without leading zeros?
> >
> > Thanks,
> > Alexander
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
(lldb) bt
 th1/fr0 supplying caller's saved pc (37)'s location, cached
  th1/fr1 pc = 0x8002ee70
 th1/fr0 supplying caller's saved r30 (30)'s location, cached
  th1/fr1 fp = 0x8004e750
 th1/fr0 supplying caller's saved r29 (29)'s location, cached
  th1/fr1 sp = 0x8004e750
  th1/fr1 using architectural default unwind method
 th1/fr0 supplying caller's saved r29 (29)'s location, cached
  th1/fr1 CFA is 0x8004e750: Register r29 (29) contents are 0x8004e750, offset 
is 0
  th1/fr1 initialized frame cfa is 0x8004e750 afa is 0x
 th1/fr0 supplying caller's saved pc (37)'s location, cached
  th1/fr1 supplying caller's saved pc (37)'s location using mips default unwind 
plan UnwindPlan
  th1/fr1 mips default unwind plan UnwindPlan tried to restore the pc from the 
link register but this is a non-zero frame
  th1/fr1 supplying caller's saved pc (37)'s location using ABI default
  th1/fr1 did not supply reg location for pc (37) because it is volatile
   th1/fr2 could not get pc value
   Frame 2 invalid RegisterContext for this frame, stopping stack walk
  th1/fr1 supplying caller's saved pc (37)'s location using mips default unwind 
plan UnwindPlan
  th1/fr1 mips default unwind plan UnwindPlan tried to restore the pc from the 
link register but this is a non-zero frame
  th1/fr1 supplying caller's saved pc (37)'s location using ABI default
  th1/fr1 did not supply reg location for pc (37) because it is volatile
   th1/fr2 could not get pc value
   Frame 2 invalid RegisterContext for this frame, stopping stack walk
 th1 Unwind of this thread is complete.
* thread #1, stop reason = instruction step into
  * frame #0: 0x800357c4
frame #1: 0x8002ee70
(lldb) memory read -a 0x8004e750
0x8004e750: 80 05 d6 a0 00 00 00 fe 00 00 00 01 00 00 00 0a  ..֠...?
0x8004e760: 00 00 00 02 80 04 e7 70 80 02 6a 6c 80

Re: [lldb-dev] How to load symfile when using debugger.CreateTarget?

2020-01-27 Thread Greg Clayton via lldb-dev 
You shouldn't have to specify it if spotlight can see your .dSYM file if you 
are on a mac. But it would be nice to have an API way to do this. The only way 
right now is to call the SBTarget::AddModule(...) function, but that won't 
correctly set the executable file and/or arch for the target correctly . There 
is a patch up for this:

https://reviews.llvm.org/D70847 

You might try:

target = debugger.CreateTarget("myapp", triple, platform_name, add_dependents, 
lldb.SBError())

followed by:

target.AddModule("myapp", triple, None, "myapp.dsym")

That might end up associating the symbol file for you, while it will re-use the 
module it first created in the CreateTarget(...) call



> On Jan 25, 2020, at 8:09 AM, Yong Lam via lldb-dev  
> wrote:
> 
> Hi all,
> 
> I can specify myapp.dsym in the lldb command line app:
> target create --no-dependents -arch arm64 --symfile myapp.dsym myapp
> 
> But how can I specify dsym file when using python API? 
> 
> ```
> target = debugger.CreateTarget(
> "myapp", triple, platform_name, add_dependents, lldb.SBError())
> ```
> 
> I have search in https://github.com/llvm/llvm-project/ 
>  and 
> https://lldb.llvm.org/python_reference/index.html 
>  . But cannot solve it.
> 
> 
> Best regards,
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[lldb-dev] [Bug 44690] New: Include guards missing for compression.h

2020-01-27 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=44690

Bug ID: 44690
   Summary: Include guards missing for compression.h
   Product: lldb
   Version: 10.0
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: ggr...@gmail.com
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org

See:

llvm-project/lldb/tools/debugserver/source/RNBRemote.cpp
Lines 43 to 45 in f15b60b
>  
> #include  
>  

Include protection is missing (HAVE_LIBCOMPRESSION).

How it should be:

llvm-project/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunication.cpp
Lines 49 to 51 in f15b60b
> #if defined(HAVE_LIBCOMPRESSION) 
> #include  
> #endif 

This was detected while updating the nixpkgs for llvm-10.

This change would imply more changes around lines 715 to 761.

Originally filed as https://github.com/llvm/llvm-project/issues/112

I suggest back porting from master to release-10.0 branch.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 44690] Include guards missing for compression.h

2020-01-27 Thread via lldb-dev 
https://bugs.llvm.org/show_bug.cgi?id=44690

Jonas Devlieghere  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Jonas Devlieghere  ---
This code is in debugserver which is macOS-only. We always have libcompresion
there. Furthermore it entirely separate from the rest of LLDB and doesn't read
the header that defines HAVE_LIBCOMPRESSION. 

I don't think you want to build debugserver for NixOS. It should only be a
target on Darwin. See tools/CMakeLists.txt:

 13 if (CMAKE_SYSTEM_NAME MATCHES "Darwin")
 14   add_lldb_tool_subdirectory(darwin-debug)
 15   if(NOT LLDB_USE_SYSTEM_DEBUGSERVER)
 16 add_lldb_tool_subdirectory(debugserver)
 17   endif()
 18 endif()

-- 
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev