Re: qXfer:exec-file:read and non multiprocess target

Gary Benson
2015-05-06T10:31:50Z

Philippe Waroquiers wrote:
> On Tue, 2015-05-05 at 12:02 +0100, Gary Benson wrote:
> > The PID is fake because vgdb does not support multiprocess
> > extensions. I don't like sending a fake/zero PID over the wire,
> > but how about I change qXfer:exec-file:read to send a NULL annex
> > if the remote does not have multiprocess extensions? Can you make
> > your side work with the patch inlined below? If so I'll tidy and
> > document it and submit it for review.
>
> It looks effectively better to not send the fake or 0 pid
> (e.g. similar to the qAttached packet).
>
> The valgrind gdbserver side works ok with the patch to send an empty
> annex. This is the resulting exchange, traced at Valgrind side:
> ...
> --4980:3: gdbsrv getpkt ("qAttached"); [no ack]
> --4980:3: gdbsrv putpkt ("$1#31"); [no ack]
> --4980:3: gdbsrv getpkt ("qXfer:exec-file:read::0,fff"); [no ack]
> --4980:3: gdbsrv putpkt ("$l/home/philippe/valgrind/better_stats/memcheck/tests/trivialleak#2c"); [no ack]
> --4980:3: gdbsrv getpkt ("vFile:open:2f686f6d652f7068696c697070652f76616c6772696e642f6265747465725f73746174732f6d656d636865636b2f74657374732f7472697669616c6c65616b,0,0"); [no ack]
> --4980:3: gdbsrv putpkt ("$#00"); [no ack]
> ...

Great, I will get that turned into a proper patch today.

> and then GDB could properly use the returned exec-file
> (even if vFile is not supported by Valgrind gdbserver).

Yes, there is a special workaround just for vgdb ;)

Cheers,
Gary

--