This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [rfc / remote protocol] Remote shared library events
- From: Daniel Jacobowitz <drow at false dot org>
- To: Jim Blandy <jimb at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org, gdb at sourceware dot org
- Date: Thu, 17 May 2007 20:27:01 -0400
- Subject: Re: [rfc / remote protocol] Remote shared library events
- References: <20070509201627.GA23422@caradoc.them.org> <m31whgv0ib.fsf@codesourcery.com>
On Wed, May 16, 2007 at 03:58:52PM -0700, Jim Blandy wrote:
> It seems odd to me that it's an @var{n} that distinguishes the reason
> for the stop; the @var{AA}, the @var{r}, and any other @var{r}:@var{n}
> pairs are essentially meaningless. I'd rather see an entirely new
> stop reply packet type --- 'L', say --- with subsequent name/value
> pairs, like those in a q[fs]DllInfo packet's 'm' response.
I don't know why you say they're meaningless. @var{AA} is unused, but
@var{r} describes the exact reason for the stop (which library was
loaded or unloaded), and other @var{r}:@var{n} pairs are treated
exactly as they are for T packets - they supply useful registers.
I'd have to add the expedited register support to any new reply packet
too, which would make it basically T without the signal number; this
version seems to complicate the protocol less.
> Should the protocol allow Key=Value pairs to appear in any order? I
> don't think you really need to revise the reply template to show this,
> just a note to that effect would be plenty.
Yes indeed.
--
Daniel Jacobowitz
CodeSourcery