[Lldb-commits] [lldb] r208423 - Documented our "attach" extension packets.

[Todd Fiala]

It's not clear in the gdb protocol docs, but the stub does launch a new
inferior process with the $A command.  (From the gdb remote docs, it looks
to me like it's just supposed to set the args, but it really is supposed to
launch it too).  That's how lldb launches an exe when talking to a
debugserver (and lldb-gdbserver).


On Sun, May 11, 2014 at 10:34 PM, Matthew Gardiner <mg11 at csr.com> wrote:

> Thanks for providing the documentation, Jim.
>
> So in the case of vAttachOrWait, if the process is not already there, what
> entity is responsible for the launching of it? Would that be the stub
> itself, or is this where lldb-platform steps in?
>
> thanks
> Matt
>
>
> Jim Ingham wrote:
>
>> Author: jingham
>> Date: Fri May  9 11:17:24 2014
>> New Revision: 208423
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=208423&view=rev
>> Log:
>> Documented our "attach" extension packets.
>>
>> Modified:
>>      lldb/trunk/docs/lldb-gdb-remote.txt
>>
>> Modified: lldb/trunk/docs/lldb-gdb-remote.txt
>> URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/docs/lldb-
>> gdb-remote.txt?rev=208423&r1=208422&r2=208423&view=diff
>> ============================================================
>> ==================
>> --- lldb/trunk/docs/lldb-gdb-remote.txt (original)
>> +++ lldb/trunk/docs/lldb-gdb-remote.txt Fri May  9 11:17:24 2014
>> @@ -1195,3 +1195,58 @@ for this region.
>>   // send packet: $qProcessInfoPID:60050#00
>>   // read packet: $pid:60050;ppid:59948;uid:
>> 7746;gid:11;euid:7746;egid:11;name:6c6c6462;triple:
>> 7838365f36342d6170706c652d6d61636f7378;#00
>>   //----------------------------------------------------------
>> ------------
>> +
>> +//----------------------------------------------------------------------
>> +// "vAttachName"
>> +//
>> +// BRIEF
>> +//  Same as vAttach, except instead of a "pid" you send a process name.
>> +//
>> +// PRIORITY TO IMPLEMENT
>> +//  Low. Only needed for "process attach -n".  If the packet isn't
>> supported
>> +//  then "process attach -n" will fail gracefully.  So you need only to
>> support
>> +//  it if attaching to a process by name makes sense for your
>> environment.
>> +//----------------------------------------------------------------------
>> +
>> +//----------------------------------------------------------------------
>> +// "vAttachWait"
>> +//
>> +// BRIEF
>> +//  Same as vAttachName, except that the stub should wait for the next
>> instance
>> +//  of a process by that name to be launched and attach to that.
>> +//
>> +// PRIORITY TO IMPLEMENT
>> +//  Low. Only needed to support "process attach -w -n" which will fail
>> +//  gracefully if the packet is not supported.
>> +//----------------------------------------------------------------------
>> +
>> +//----------------------------------------------------------------------
>> +// "qAttachOrWaitSupported"
>> +//
>> +// BRIEF
>> +//  This is a binary "is it supported" query.  Return OK if you support
>> +//  vAttachOrWait
>> +//
>> +// PRIORITY TO IMPLEMENT
>> +//  Low. This is required if you support vAttachOrWait, otherwise no
>> support
>> +//  is needed since the standard "I don't recognize this packet" response
>> +//  will do the right thing.
>> +//----------------------------------------------------------------------
>> +
>> +//----------------------------------------------------------------------
>> +// "vAttachOrWait"
>> +//
>> +// BRIEF
>> +//  Same as vAttachWait, except that the stub will attach to a process
>> +//  by name if it exists, and if it does not, it will wait for a process
>> +//  of that name to appear and attach to it.
>> +//
>> +// PRIORITY TO IMPLEMENT
>> +//  Low. Only needed to implement "process attach -w -i false -n".  If
>> +//  you don't implement it but do implement -n AND lldb can somehow get
>> +//  a process list from your device, it will fall back on scanning the
>> +//  process list, and sending vAttach or vAttachWait depending on
>> +//  whether the requested process exists already.  This is racy,
>> +//  however, so if you want to support this behavior it is better to
>> +//  support this packet.
>> +//----------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> lldb-commits mailing list
>> lldb-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
>>
>>
>>   To report this email as spam click https://www.mailcontrol.com/
>> sr/MZbqvYs5QwJvpeaetUwhCQ== .
>>
>
>
>
> Member of the CSR plc group of companies. CSR plc registered in England
> and Wales, registered number 4187346, registered office Churchill House,
> Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
> More information can be found at www.csr.com. Keep up to date with CSR on
> our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people,
> YouTube, www.youtube.com/user/CSRplc, Facebook,
> www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
> www.twitter.com/CSR_plc.
> New for 2014, you can now access the wide range of products powered by
> aptX at www.aptx.com.
>
> _______________________________________________
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
>



-- 
Todd Fiala | Software Engineer | tfiala at google.com | 650-943-3180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20140512/19d0a9a7/attachment.html>