GDB RSP qVAttachOrWaitSupported

Hi,

I'm testing the "gdb-remote" command from a recent(ish) build of lldb on 64-bit linux running against an in-house gdbserver.

I'm seeing the message "$qVAttachOrWaitSupported" in the trace coming from lldb. This looks like an lldb extension to GDB-RSP, but I can't find any information on this message from docs/lldb-gdb-remote.txt.

Could somebody explain this message's purpose and supply the required response syntax?

thanks
Matthew Gardiner

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.

RNBRemote::HandlePacket_qVAttachOrWaitSupported has the following comments which may give you some idea.
    // We support attachOrWait meaning attach if the process exists, otherwise wait to attach.

Regards,
Abid

Abid, Hafiz wrote:

RNBRemote::HandlePacket_qVAttachOrWaitSupported has the following comments which may give you some idea.
     // We support attachOrWait meaning attach if the process exists, otherwise wait to attach.

Ok, thanks.

So this whole entity "VAttachOrWaitSupported" is a concept which the stub does or not support, correct?

If so, does the stub write back "1", if it does support it, otherwise "0"?

Presumably if the stub does support this feature, are there any other messages which the stub should then support?

I'm still not really clear what's happening here....

Matt

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.

I have not read the documentation for this packet. But looking at the code,
It seems that you will return OK if your stub supports this packet. Otherwise an empty reply can
Indicate that packet is not supported.

Please look at the following link for more details about query packets.

Thanks,
Abid

Hey Matthew,

Essentially you’ll want to return a string like this:
$OK#9a

if your gdb remote debug monitor can handle that (undocumented) element, or return this:
$#00

if you do not support the packet.

I’ve been digging into the protocol lately since I’m adding tests for gdb remote protocol-layer activity, so that I can verify lldb-gdbserver (llgs) on Linux is acting identically to debugserver on MacOSX (and to make it easier for us to transition from debugserver to llgs).

I had noted that packet wasn’t documented a while back. When I get to testing that one, I’ll update the doc text file on it.

My bad, there are actually a bunch of vAttach variant packets we added to support attaching by process name, and "wait for a process to show up and then attach to it" and the like.

I added documentation for them.

Jim

Note also as a general rule, you never need to add support for a query packet unless you support the thing it is querying for, since whoever is sending it is supposed to take the "unrecognized packet" error to mean not supported.

Jim

Thanks, Jim!

Oh right, good point.

All the remote sides I worked with essentially have a default incoming packet rule that says “if I don’t know what this is, respond with $#00”, so no need to add that explicitly if your remote side already does that, Matthew.

-Todd

Oh right, good point.

All the remote sides I worked with essentially have a default incoming packet rule that says "if I don't know what this is, respond with $#00", so no need to add that explicitly if your remote side already does that, Matthew.

That's actually a requirement of the protocol (from E.1 Overview):

    For any command not supported by the stub, an empty response (‘$#00’) should be returned.

Jim

jingham@apple.com wrote:

My bad, there are actually a bunch of vAttach variant packets we added to support attaching by process name, and "wait for a process to show up and then attach to it" and the like.

I added documentation for them.

Jim

Thanks for this Jim,
I'll read up your documentation and get back if needs be.
Matt

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.