Re: [lldb-dev] RFC for DWZ = DW_TAG_imported_unit + DWARF-5 supplementary files

[Greg Clayton via lldb-dev]

> On Aug 23, 2017, at 2:06 PM, Jan Kratochvil via lldb-dev 
>  wrote:
> 
> Hello,
> 
> at least Fedora Linux distribution uses DWZ to reduce DWARF debug info size:
>   https://fedoraproject.org/wiki/Features/DwarfCompressor
> 
> It is DWARF optimization - not really a compression.  One can find it by
> DW_TAG_partial_unit/DW_TAG_imported_unit:
> <0>: Abbrev Number: 103 (DW_TAG_partial_unit)
>   DW_AT_stmt_list   : 0x0
><10>   DW_AT_comp_dir: (alt indirect string, offset: 0xe61c)
> <1><14>: Abbrev Number: 45 (DW_TAG_imported_unit)
><15>   DW_AT_import  : 
> ...
> 
> I have already made some attempt for its implementation:
>   https://people.redhat.com/jkratoch/lldb-2017-08-13.patch
>   https://people.redhat.com/jkratoch/lldb-2017-08-13imp.patch
> 
> But I found that approach as a dead-end because LLDB expects all the DIEs from
> a CU really belong to the same DWARFCompileUnit.  Contrary to LLDB
> expectations the patch above creates different DWARFCompileUnit for each
> DW_TAG_partial_unit.  This the patch solves for cross-DIE references but then
> it ends up with:
>   tools/clang/lib/AST/DeclBase.cpp:75:
>   Assertion `!Parent || >getParentASTContext() == ' failed.
> as GetCompUnitForDWARFCompUnit() is returning different clang context for DIEs
> from DWZ supplementary files (different SymbolFileDWARF) vs. base file CUs.
> I tried to generate alternative user_id_t to always refer to originating CU in
> the base file but it is more and more complicated.
> 
> Therefore I would like a new approach to keep all the DIEs from
> a DW_TAG_compile_unit incl. all its imported DW_TAG_partial_unit in the same
> DWARFCompileUnit.  So far I wanted to prevent expansion/copy of all
> DW_TAG_partial_unit m_die_array data into each of its parent
> DW_TAG_compile_unit as it may be a performance hit.
> 
> But then I am not sure whether it is worth it - when LLDB does fully populate
> m_die_array?

It expands them in:

size_t DWARFCompileUnit::ExtractDIEsIfNeeded(bool cu_die_only);

It will either only make the top level CU DIE, or it will parse all DIEs.

>  Currently it always has to as on non-OSX platforms it is using
> DWARFCompileUnit::Index(). But as I plan to implement DWARF-5 .debug_names
> index (like __apple_* index) maybe LLDB then no longer needs to populate
> m_die_array and so just expanding all DW_TAG_partial_unit into a single
> m_die_array for each DW_TAG_compile_unit is fine?

So I glossed over the documentation and I gathered that DWARF type info might 
be stored in other DWARF files and references from the current file.

SymbolFileDWARFDebugMap is an example of how we do things on MacOS. We have one 
clang::ASTContext in the SymbolFileDWARFDebugMap, and multiple external .o 
files (where each ins a SymbolFileDWARF instance) that contain unlinked DWARF. 
Each SymbolFileDWARF instance will have:

  void SymbolFileDWARF::SetDebugMapModule(const lldb::ModuleSP _sp);

called to indicate it is actually part of the SymbolFileDWARFDebugMap. Then 
there are functions that check the debug map file and return the 
UniqueDWARFASTTypeMap or the TypeSystem from the SymbolFileDWARFDebugMap if we 
have one:


UniqueDWARFASTTypeMap ::GetUniqueDWARFASTTypeMap() {
  SymbolFileDWARFDebugMap *debug_map_symfile = GetDebugMapSymfile();
  if (debug_map_symfile)
return debug_map_symfile->GetUniqueDWARFASTTypeMap();
  else
return m_unique_ast_type_map;
}

TypeSystem *SymbolFileDWARF::GetTypeSystemForLanguage(LanguageType language) {
  SymbolFileDWARFDebugMap *debug_map_symfile = GetDebugMapSymfile();
  TypeSystem *type_system;
  if (debug_map_symfile) {
type_system = debug_map_symfile->GetTypeSystemForLanguage(language);
  } else {
type_system = m_obj_file->GetModule()->GetTypeSystemForLanguage(language);
if (type_system)
  type_system->SetSymbolFile(this);
  }
  return type_system;
}

This allows one master DWARF file to use a bunch of other DWARF files to make 
one cohesive debug info. That is one approach you could use, but you would need 
to not affect the SymbolFileDWARFDebugMap with any changes you made.

One other idea is to keep all DWARF files separate and stand alone. Your main 
DWARF file with one or more DW_TAG_imported_unit and all DW_TAG_imported_unit 
referenced files, each as its own SymbolFileDWARF. Any reference to a 
DW_FORM_ref_alt would turn into a forward declaration in the current 
SymbolFileDWARF, so the ASTContext in each SymbolFileDWARF wouldn't know 
anything about the types, but we would need to add the DW_TAG_imported_unit 
object files to the target, and _they_ would know about any types they own. 
This way you could have multiple libraries that are the main top level DWARF 
files refer to a bunch of common DW_TAG_imported_unit files with type info and 
and those files would only be loaded once. We would rely on LLDB being able to 
track down the forward declared types later when the variables need to get 

Re: [lldb-dev] Forcing lldb to refresh process state

[Greg Clayton via lldb-dev]

> On Aug 23, 2017, at 1:37 PM, Vadim Chugunov  wrote:
> 
> 
> On Wed, Aug 23, 2017 at 12:37 PM, Greg Clayton  > wrote:
> This isn't a work around right? You should be triggering your reverse step or 
> reverse continue using a "process reverse-continue" or "thread reverse-step" 
> right? If you do this, everything will just work. There should be no way this 
> happens automagically without user interaction. Am I missing something?
> 
> Wait a second... As far as I know, LLDB itself does not support 
> reverse-debugging (unless I missed something in a major way).  So there is no 
> "process reverse-continue" command, is there?
> 
> I am not talking about adding proper reverse-debugging to lldb.  All I want 
> to do is to hack together a script that emulates "process reverse-continue" 
> in cases when remote target happens to support it.   I'm sending commands 
> directly to remote gdb via `process plugin packet send bs`, but that leaves 
> lldb out of the loop because it does not analyze the response packet.

Not sure why we wouldn't add it? It would be easy. The default implementation 
would return an unsupported error, and the ProcessGDBRemote would just pass the 
packets down.

Anything that internally calls lldb_private::Process::Flush() should do the 
trick as long as it actually causes it to get called. So:

target modules add
target modules load
target symbols add

They flush the process state because if you add a module or symbols or move a 
module around in memory we need to redo all stack traces. So you will need to 
do one of these as a work around and the command must succeed. I would suggest 
using:

(lldb) target modules add ...

where ... is the path of a shared library or executable that isn't in your 
target.


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

Re: [lldb-dev] Forcing lldb to refresh process state

[Vadim Chugunov via lldb-dev]

On Wed, Aug 23, 2017 at 12:37 PM, Greg Clayton  wrote:

> This isn't a work around right? You should be triggering your reverse step
> or reverse continue using a "process reverse-continue" or "thread
> reverse-step" right? If you do this, everything will just work. There
> should be no way this happens automagically without user interaction. Am I
> missing something?
>

Wait a second... As far as I know, LLDB itself does not support
reverse-debugging (unless I missed something in a major way).  So there is
no "process reverse-continue" command, is there?

I am not talking about adding proper reverse-debugging to lldb.  All I want
to do is to hack together a script that emulates "process reverse-continue"
in cases when remote target happens to support it.   I'm sending commands
directly to remote gdb via `process plugin packet send bs`, but that leaves
lldb out of the loop because it does not analyze the response packet.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Forcing lldb to refresh process state

[Greg Clayton via lldb-dev]

This isn't a work around right? You should be triggering your reverse step or 
reverse continue using a "process reverse-continue" or "thread reverse-step" 
right? If you do this, everything will just work. There should be no way this 
happens automagically without user interaction. Am I missing something?


> On Aug 23, 2017, at 12:03 PM, Vadim Chugunov  wrote:
> 
> Yeah, this `bs` + `stepi` dance is the only workaround I found so far.
> 
> On Wed, Aug 23, 2017 at 10:40 AM, Greg Clayton  > wrote:
> There is a standard for reverse stepping where the GDB remote protocol was 
> extended to do the reverse stepping. See:
> 
> https://sourceware.org/gdb/onlinedocs/gdb/Packets.html 
> 
> 
> Look for "reverse" in the text. They added "bc" for reverse continue and "bs" 
> for reverse step. We should be using these if possible.
> 
> 
> 
>> On Aug 23, 2017, at 10:00 AM, Ted Woodward > > wrote:
>> 
>> Perhaps a manual packet that tells your remote server that the next “s” 
>> packet is a reverse step, then run the lldb command “si”.
>>  

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

Re: [lldb-dev] Forcing lldb to refresh process state

[Vadim Chugunov via lldb-dev]

Yeah, this `bs` + `stepi` dance is the only workaround I found so far.

On Wed, Aug 23, 2017 at 10:40 AM, Greg Clayton  wrote:

> There is a standard for reverse stepping where the GDB remote protocol was
> extended to do the reverse stepping. See:
>
> https://sourceware.org/gdb/onlinedocs/gdb/Packets.html
>
> Look for "reverse" in the text. They added "bc" for reverse continue and
> "bs" for reverse step. We should be using these if possible.
>
>
> On Aug 23, 2017, at 10:00 AM, Ted Woodward 
> wrote:
>
> Perhaps a manual packet that tells your remote server that the next “s”
> packet is a reverse step, then run the lldb command “si”.
>
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Remote debugging ARM target from x86 host

[Ted Woodward via lldb-dev]

What should be happening is Handle_qLaunchGDBServer calls LaunchGDBServer with 
a port of UINT16_MAX, which tells it to use a port in its port list. It 
shouldn't have a port list, so should return 0. LaunchGDBServer calls 
StartDebugServerProcess with a port of 0 in the url. StartDebugServerProcess 
launches the gdbserver with a named pipe, and reads the actual port from the 
pipe.

I suggest turning on more logging - specifically, "gdb-remote process". That's 
the channel used in StartDebugServerProcess.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

> -Original Message-
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg
> Clayton via lldb-dev
> Sent: Wednesday, August 23, 2017 12:45 PM
> To: Hans Wennborg 
> Cc: Ramana ; LLDB Dev  d...@lists.llvm.org>
> Subject: Re: [lldb-dev] Remote debugging ARM target from x86 host
> 
> Port zero should never be returned as a valid port. We do bind to port zero 
> just
> so we don't try and pick a port at random just to find it is being used. When 
> we
> bind to port 9, we must find the actual port we bound to and return that. 
> Seems
> something has gone wrong with the code that discovers the port that was
> actually bound and is not reporting that back correctly.
> 
> 
> Should be straight forward to do by debugging the function
> GDBRemoteCommunicationServerPlatform::Handle_qLaunchGDBServer(...) in
> GDBRemoteCommunicationServerPlatform.cpp and see what is going on and
> why it is returning 0 as the port.
> 
> Greg
> 
> > On Aug 23, 2017, at 9:44 AM, Hans Wennborg via lldb-dev  d...@lists.llvm.org> wrote:
> >
> > This was marked as an lldb 5.0.0 release blocker since it's a
> > regression from 4.0.1: https://bugs.llvm.org/show_bug.cgi?id=34183
> >
> > lldb-dev: Is there any interest in fixing this bug?
> >
> > On Fri, Aug 4, 2017 at 10:13 PM, Ramana via lldb-dev
> >  wrote:
> >> Hi,
> >>
> >> I am trying to remote debug ARM (linux) target from x86 (linux) host
> >> and I am getting the following error while trying to launch a process.
> >> The local debugging on ARM works.
> >>
> >> error: connect remote failed (invalid host:port specification:
> >> '10.10.2.3')
> >> error: process launch failed: invalid host:port specification: '10.10.2.3'
> >>
> >> It appears the above error is because the gdb-remote is returning the
> >> communication port as zero.
> >>
> >> <  36> send packet: $qLaunchGDBServer;host:svrlin249;#bb
> >> <  19> read packet: $pid:298;port:0;#bf
> >>
> >> What are the possible reasons for the above behavior from gdb-remote
> >> and how I could resolve this?
> >>
> >> If it helps, below is the full log.
> >>
> >> (lldb) log enable lldb comm
> >> (lldb) log enable gdb-remote packets
> >> (lldb) platform select remote-linux
> >>  Platform: remote-linux
> >> Connected: no
> >> (lldb) platform connect connect://10.10.2.3:500
> >> 0x915bd78 Communication::Communication (name = gdb-remote.client)
> >> 0x915bd78 Communication::Disconnect ()
> >> 0x915bd78 Communication::Disconnect ()
> >> 0x915bd78 Communication::Connect (url = connect://10.10.2.3:500)
> >> Socket::TcpConnect (host/port = 10.10.2.3:500) TCPSocket::Connect
> >> (host/port = 10.10.2.3:500)
> >> 0x915bd78 Communication::Write (src = 0xbfcb7433, src_len = 1)
> >> connection = 0x915f578
> >> 0x915f608 Socket::Write() (socket = 7, src = 0xbfcb7433, src_len = 1,
> >> flags = 0) => 1 (error = (null))
> >> <   1> send packet: +
> >> this = 0x0915BD78, dst = 0xBFCB53EC, dst_len = 8192, timeout = 1
> >> us, connection = 0x0915F578
> >> 0x915bd78 Communication::Write (src = 0x916022c, src_len = 19)
> >> connection = 0x915f578
> >> 0x915f608 Socket::Write() (socket = 7, src = 0x916022c, src_len = 19,
> >> flags = 0) => 19 (error = (null))
> >> history[1] tid=0x7cbf <   1> send packet: +
> >> <  19> send packet: $QStartNoAckMode#b0 this = 0x0915BD78, dst =
> >> 0xBFCB51AC, dst_len = 8192, timeout = 600 us, connection =
> >> 0x0915F578
> >> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb51ac, src_len = 7,
> >> flags = 0) => 7 (error = (null))
> >> <   1> read packet: +
> >> <   6> read packet: $OK#9a
> >> 0x915bd78 Communication::Write (src = 0xbfcb50f3, src_len = 1)
> >> connection = 0x915f578
> >> 0x915f608 Socket::Write() (socket = 7, src = 0xbfcb50f3, src_len = 1,
> >> flags = 0) => 1 (error = (null))
> >> <   1> send packet: +
> >> 0x915bd78 Communication::Write (src = 0x9161ff4, src_len = 13)
> >> connection = 0x915f578
> >> 0x915f608 Socket::Write() (socket = 7, src = 0x9161ff4, src_len = 13,
> >> flags = 0) => 13 (error = (null)) <  13> send packet: $qHostInfo#9b
> >> this = 0x0915BD78, dst = 0xBFCB510C, dst_len = 8192, timeout =
> >> 100 us, connection = 0x0915F578
> >> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb510c, src_len =
> >> 316, flags = 0) => 316 (error = 

Re: [lldb-dev] Remote debugging ARM target from x86 host

[Greg Clayton via lldb-dev]

Port zero should never be returned as a valid port. We do bind to port zero 
just so we don't try and pick a port at random just to find it is being used. 
When we bind to port 9, we must find the actual port we bound to and return 
that. Seems something has gone wrong with the code that discovers the port that 
was actually bound and is not reporting that back correctly. 


Should be straight forward to do by debugging the function 
GDBRemoteCommunicationServerPlatform::Handle_qLaunchGDBServer(...) in 
GDBRemoteCommunicationServerPlatform.cpp and see what is going on and why it is 
returning 0 as the port.

Greg

> On Aug 23, 2017, at 9:44 AM, Hans Wennborg via lldb-dev 
>  wrote:
> 
> This was marked as an lldb 5.0.0 release blocker since it's a
> regression from 4.0.1: https://bugs.llvm.org/show_bug.cgi?id=34183
> 
> lldb-dev: Is there any interest in fixing this bug?
> 
> On Fri, Aug 4, 2017 at 10:13 PM, Ramana via lldb-dev
>  wrote:
>> Hi,
>> 
>> I am trying to remote debug ARM (linux) target from x86 (linux) host
>> and I am getting the following error while trying to launch a process.
>> The local debugging on ARM works.
>> 
>> error: connect remote failed (invalid host:port specification: '10.10.2.3')
>> error: process launch failed: invalid host:port specification: '10.10.2.3'
>> 
>> It appears the above error is because the gdb-remote is returning the
>> communication port as zero.
>> 
>> <  36> send packet: $qLaunchGDBServer;host:svrlin249;#bb
>> <  19> read packet: $pid:298;port:0;#bf
>> 
>> What are the possible reasons for the above behavior from gdb-remote
>> and how I could resolve this?
>> 
>> If it helps, below is the full log.
>> 
>> (lldb) log enable lldb comm
>> (lldb) log enable gdb-remote packets
>> (lldb) platform select remote-linux
>>  Platform: remote-linux
>> Connected: no
>> (lldb) platform connect connect://10.10.2.3:500
>> 0x915bd78 Communication::Communication (name = gdb-remote.client)
>> 0x915bd78 Communication::Disconnect ()
>> 0x915bd78 Communication::Disconnect ()
>> 0x915bd78 Communication::Connect (url = connect://10.10.2.3:500)
>> Socket::TcpConnect (host/port = 10.10.2.3:500)
>> TCPSocket::Connect (host/port = 10.10.2.3:500)
>> 0x915bd78 Communication::Write (src = 0xbfcb7433, src_len = 1)
>> connection = 0x915f578
>> 0x915f608 Socket::Write() (socket = 7, src = 0xbfcb7433, src_len = 1,
>> flags = 0) => 1 (error = (null))
>> <   1> send packet: +
>> this = 0x0915BD78, dst = 0xBFCB53EC, dst_len = 8192, timeout = 1
>> us, connection = 0x0915F578
>> 0x915bd78 Communication::Write (src = 0x916022c, src_len = 19)
>> connection = 0x915f578
>> 0x915f608 Socket::Write() (socket = 7, src = 0x916022c, src_len = 19,
>> flags = 0) => 19 (error = (null))
>> history[1] tid=0x7cbf <   1> send packet: +
>> <  19> send packet: $QStartNoAckMode#b0
>> this = 0x0915BD78, dst = 0xBFCB51AC, dst_len = 8192, timeout = 600
>> us, connection = 0x0915F578
>> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb51ac, src_len = 7,
>> flags = 0) => 7 (error = (null))
>> <   1> read packet: +
>> <   6> read packet: $OK#9a
>> 0x915bd78 Communication::Write (src = 0xbfcb50f3, src_len = 1)
>> connection = 0x915f578
>> 0x915f608 Socket::Write() (socket = 7, src = 0xbfcb50f3, src_len = 1,
>> flags = 0) => 1 (error = (null))
>> <   1> send packet: +
>> 0x915bd78 Communication::Write (src = 0x9161ff4, src_len = 13)
>> connection = 0x915f578
>> 0x915f608 Socket::Write() (socket = 7, src = 0x9161ff4, src_len = 13,
>> flags = 0) => 13 (error = (null))
>> <  13> send packet: $qHostInfo#9b
>> this = 0x0915BD78, dst = 0xBFCB510C, dst_len = 8192, timeout = 100
>> us, connection = 0x0915F578
>> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb510c, src_len = 316,
>> flags = 0) => 316 (error = (null))
>> < 316> read packet:
>> $triple:61726d2d2d6c696e75782d676e75656162696866;ptrsize:4;watchpoint_exceptions_received:before;endian:little;os_version:3.10.31;os_build:332e31302e33312d6c7473692d30323836312d6738303161343066;os_kernel:233520534d5020467269204d61792031332031353a35383a3232204953542032303136;hostname:736f
>> 63667067615f617272696135;#0a
>> 0x915bd78 Communication::Write (src = 0x915fe9c, src_len = 18)
>> connection = 0x915f578
>> 0x915f608 Socket::Write() (socket = 7, src = 0x915fe9c, src_len = 18,
>> flags = 0) => 18 (error = (null))
>> <  18> send packet: $qGetWorkingDir#91
>> this = 0x0915BD78, dst = 0xBFCB50FC, dst_len = 8192, timeout = 100
>> us, connection = 0x0915F578
>> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb50fc, src_len = 24,
>> flags = 0) => 24 (error = (null))
>> <  24> read packet: $2f686f6d652f726f6f74#4b
>> 0x915bd78 Communication::Write (src = 0x915fe9c, src_len = 19)
>> connection = 0x915f578
>> 0x915f608 Socket::Write() (socket = 7, src = 0x915fe9c, src_len = 19,
>> flags = 0) => 19 (error = (null))
>> <  19> send packet: $qQueryGDBServer#cb
>> this = 0x0915BD78, dst = 0xBFCB531C, dst_len = 8192, timeout = 100

Re: [lldb-dev] Forcing lldb to refresh process state

[Greg Clayton via lldb-dev]

There is a standard for reverse stepping where the GDB remote protocol was 
extended to do the reverse stepping. See:

https://sourceware.org/gdb/onlinedocs/gdb/Packets.html 


Look for "reverse" in the text. They added "bc" for reverse continue and "bs" 
for reverse step. We should be using these if possible.



> On Aug 23, 2017, at 10:00 AM, Ted Woodward  
> wrote:
> 
> Perhaps a manual packet that tells your remote server that the next “s” 
> packet is a reverse step, then run the lldb command “si”.
>  
> It would be simpler, from a packet log analysis standpoint, if you weren’t 
> stopped at a breakpoint location when you did this.
>  
>  
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
> Linux Foundation Collaborative Project
>  
> From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg 
> Clayton via lldb-dev
> Sent: Tuesday, August 22, 2017 6:20 PM
> To: Vadim Chugunov 
> Cc: LLDB 
> Subject: Re: [lldb-dev] Forcing lldb to refresh process state
>  
> You need to send some sort of continue through the GDB remote interface. The 
> only way to get a $T packet back is in response to a "?" packet or to a 
> "vCont" or other continue or step packet.
>  
>> On Aug 22, 2017, at 2:30 PM, Vadim Chugunov > > wrote:
>>  
>> It does send '$T05...' in response, but it looks like lldb does not analyze 
>> responses to manually sent packets.
>>  
>> On Mon, Aug 21, 2017 at 1:02 PM, Greg Clayton > > wrote:
>>> If you do a reverse step it actually should send a process resumed and a 
>>> process stopped event.
>>> 
>>> > On Aug 18, 2017, at 7:19 PM, Vadim via lldb-dev >> > > wrote:
>>> >
>>> > I'm trying to reverse-step.  So I think I'd need to refresh all thread 
>>> > states?
>>> >
>>> >> On Aug 18, 2017, at 4:50 PM, Jim Ingham >> >> > wrote:
>>> >>
>>> >> No, there hasn't been a need for this.
>>> >>
>>> >> What commands are you planning to send?  Or equivalently, how much state 
>>> >> are you expecting to change?
>>> >>
>>> >> Jim
>>> >>
>>> >>> On Aug 18, 2017, at 4:36 PM, Vadim Chugunov via lldb-dev 
>>> >>> > wrote:
>>> >>>
>>> >>> Hi,
>>> >>> Is there any way to force lldb to refresh it's internal record of 
>>> >>> debuggee process state (as if it had just received a stop event)?  I 
>>> >>> want to send a custom command to remote gdb process stub (via `process 
>>> >>> plugin packet send`).  This works, but if the command alters debuggee 
>>> >>> state, lldb won't know about it.
>>> >>> ___
>>> >>> 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 
>>> > 
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Forcing lldb to refresh process state

[Ted Woodward via lldb-dev]

Perhaps a manual packet that tells your remote server that the next "s"
packet is a reverse step, then run the lldb command "si".

 

It would be simpler, from a packet log analysis standpoint, if you weren't
stopped at a breakpoint location when you did this.

 

 

--

Qualcomm Innovation Center, Inc.

The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project

 

From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Greg
Clayton via lldb-dev
Sent: Tuesday, August 22, 2017 6:20 PM
To: Vadim Chugunov 
Cc: LLDB 
Subject: Re: [lldb-dev] Forcing lldb to refresh process state

 

You need to send some sort of continue through the GDB remote interface. The
only way to get a $T packet back is in response to a "?" packet or to a
"vCont" or other continue or step packet.

 

On Aug 22, 2017, at 2:30 PM, Vadim Chugunov  > wrote:

 

It does send '$T05...' in response, but it looks like lldb does not analyze
responses to manually sent packets.

 

On Mon, Aug 21, 2017 at 1:02 PM, Greg Clayton  > wrote:

If you do a reverse step it actually should send a process resumed and a
process stopped event.

> On Aug 18, 2017, at 7:19 PM, Vadim via lldb-dev  > wrote:
>
> I'm trying to reverse-step.  So I think I'd need to refresh all thread
states?
>
>> On Aug 18, 2017, at 4:50 PM, Jim Ingham  > wrote:
>>
>> No, there hasn't been a need for this.
>>
>> What commands are you planning to send?  Or equivalently, how much state
are you expecting to change?
>>
>> Jim
>>
>>> On Aug 18, 2017, at 4:36 PM, Vadim Chugunov via lldb-dev
 > wrote:
>>>
>>> Hi,
>>> Is there any way to force lldb to refresh it's internal record of
debuggee process state (as if it had just received a stop event)?  I want to
send a custom command to remote gdb process stub (via `process plugin packet
send`).  This works, but if the command alters debuggee state, lldb won't
know about it.
>>> ___
>>> 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

 

 

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

Re: [lldb-dev] Remote debugging ARM target from x86 host

[Hans Wennborg via lldb-dev]

This was marked as an lldb 5.0.0 release blocker since it's a
regression from 4.0.1: https://bugs.llvm.org/show_bug.cgi?id=34183

lldb-dev: Is there any interest in fixing this bug?

On Fri, Aug 4, 2017 at 10:13 PM, Ramana via lldb-dev
 wrote:
> Hi,
>
> I am trying to remote debug ARM (linux) target from x86 (linux) host
> and I am getting the following error while trying to launch a process.
> The local debugging on ARM works.
>
> error: connect remote failed (invalid host:port specification: '10.10.2.3')
> error: process launch failed: invalid host:port specification: '10.10.2.3'
>
> It appears the above error is because the gdb-remote is returning the
> communication port as zero.
>
> <  36> send packet: $qLaunchGDBServer;host:svrlin249;#bb
> <  19> read packet: $pid:298;port:0;#bf
>
> What are the possible reasons for the above behavior from gdb-remote
> and how I could resolve this?
>
> If it helps, below is the full log.
>
> (lldb) log enable lldb comm
> (lldb) log enable gdb-remote packets
> (lldb) platform select remote-linux
>   Platform: remote-linux
>  Connected: no
> (lldb) platform connect connect://10.10.2.3:500
> 0x915bd78 Communication::Communication (name = gdb-remote.client)
> 0x915bd78 Communication::Disconnect ()
> 0x915bd78 Communication::Disconnect ()
> 0x915bd78 Communication::Connect (url = connect://10.10.2.3:500)
> Socket::TcpConnect (host/port = 10.10.2.3:500)
> TCPSocket::Connect (host/port = 10.10.2.3:500)
> 0x915bd78 Communication::Write (src = 0xbfcb7433, src_len = 1)
> connection = 0x915f578
> 0x915f608 Socket::Write() (socket = 7, src = 0xbfcb7433, src_len = 1,
> flags = 0) => 1 (error = (null))
> <   1> send packet: +
> this = 0x0915BD78, dst = 0xBFCB53EC, dst_len = 8192, timeout = 1
> us, connection = 0x0915F578
> 0x915bd78 Communication::Write (src = 0x916022c, src_len = 19)
> connection = 0x915f578
> 0x915f608 Socket::Write() (socket = 7, src = 0x916022c, src_len = 19,
> flags = 0) => 19 (error = (null))
> history[1] tid=0x7cbf <   1> send packet: +
> <  19> send packet: $QStartNoAckMode#b0
> this = 0x0915BD78, dst = 0xBFCB51AC, dst_len = 8192, timeout = 600
> us, connection = 0x0915F578
> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb51ac, src_len = 7,
> flags = 0) => 7 (error = (null))
> <   1> read packet: +
> <   6> read packet: $OK#9a
> 0x915bd78 Communication::Write (src = 0xbfcb50f3, src_len = 1)
> connection = 0x915f578
> 0x915f608 Socket::Write() (socket = 7, src = 0xbfcb50f3, src_len = 1,
> flags = 0) => 1 (error = (null))
> <   1> send packet: +
> 0x915bd78 Communication::Write (src = 0x9161ff4, src_len = 13)
> connection = 0x915f578
> 0x915f608 Socket::Write() (socket = 7, src = 0x9161ff4, src_len = 13,
> flags = 0) => 13 (error = (null))
> <  13> send packet: $qHostInfo#9b
> this = 0x0915BD78, dst = 0xBFCB510C, dst_len = 8192, timeout = 100
> us, connection = 0x0915F578
> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb510c, src_len = 316,
> flags = 0) => 316 (error = (null))
> < 316> read packet:
> $triple:61726d2d2d6c696e75782d676e75656162696866;ptrsize:4;watchpoint_exceptions_received:before;endian:little;os_version:3.10.31;os_build:332e31302e33312d6c7473692d30323836312d6738303161343066;os_kernel:233520534d5020467269204d61792031332031353a35383a3232204953542032303136;hostname:736f
> 63667067615f617272696135;#0a
> 0x915bd78 Communication::Write (src = 0x915fe9c, src_len = 18)
> connection = 0x915f578
> 0x915f608 Socket::Write() (socket = 7, src = 0x915fe9c, src_len = 18,
> flags = 0) => 18 (error = (null))
> <  18> send packet: $qGetWorkingDir#91
> this = 0x0915BD78, dst = 0xBFCB50FC, dst_len = 8192, timeout = 100
> us, connection = 0x0915F578
> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb50fc, src_len = 24,
> flags = 0) => 24 (error = (null))
> <  24> read packet: $2f686f6d652f726f6f74#4b
> 0x915bd78 Communication::Write (src = 0x915fe9c, src_len = 19)
> connection = 0x915f578
> 0x915f608 Socket::Write() (socket = 7, src = 0x915fe9c, src_len = 19,
> flags = 0) => 19 (error = (null))
> <  19> send packet: $qQueryGDBServer#cb
> this = 0x0915BD78, dst = 0xBFCB531C, dst_len = 8192, timeout = 100
> us, connection = 0x0915F578
> 0x915f608 Socket::Read() (socket = 7, src = 0xbfcb531c, src_len = 7,
> flags = 0) => 7 (error = (null))
> <   7> read packet: $E04#a9
>   Platform: remote-linux
> Triple: arm-*-linux-gnueabihf
> OS Version: 3.10.31 (3.10.31-ltsi-02861-g801a40f)
> Kernel: #5 SMP Fri May 13 15:58:22 IST 2016
>   Hostname: socfpga_arria5
>  Connected: yes
> WorkingDir: /home/root
> (lldb) file main
> 0x915bd78 Communication::Write (src = 0x91638fc, src_len = 137)
> connection = 0x915f578
> 0x915f608 Socket::Write() (socket = 7, src = 0x91638fc, src_len = 137,
> flags = 0) => 137 (error = (null))
> < 137> send packet:
> $qModuleInfo:2f686f6d652f72616d616e616e2f776f726b5f726f6f742f546f545f6c6c64622f74657374732f6d61696e;61726d2d2d6c696e75782d656162696866#f1
> this = 0x0915BD78, dst =