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

[Greg Clayton]

> On 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?

Anything can launch it and it won't be debugserver. It will just poll the OS until it finds something to attach to. On MacOSX we make sure to be a bit smart about what we try to attach to and we avoid:
- any processes that are already being debugged
- any processes that are zombies or aren't in a good state


> Would that be the stub itself, or is this where lldb-platform steps in?

No, you should be launching the process if you want to launch it. vAttach is for processes that are already running (attach to an existing pid or app by name) and the "Wait" part just means someone else will launch it.

> 
> 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