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: Jim Blandy <jimb at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: gdb at sourceware dot org
- Date: Wed, 16 May 2007 15:58:52 -0700
- Subject: Re: [rfc / remote protocol] Remote shared library events
- References: <20070509201627.GA23422@caradoc.them.org>
Daniel Jacobowitz <drow@false.org> writes:
> All comments welcome!
>
> +@item
> +If @var{n} is @samp{load}, then the packet indicates a DLL load event,
> +and @var{r} describes the newly loaded library. The library format is
> +the same used in @samp{qfDllInfo} replies (@pxref{qfDllInfo}), e.g.@:
> +@samp{load:Name=@var{hexname},TextSeg=@var{textaddr}}. The entry may
> +end in @samp{,nop} if this library was already mapped, e.g.@: by an
> +earlier call to @code{LoadLibrary}. @var{aa} should be @samp{05}, the
> +trap signal.
> +
> +@item
> +If @var{n} is @samp{unload}, then the packet indicates a DLL unload
> +event, and @var{r} describes the unloaded library. @var{r} is a list
> +of comma-separated @samp{Key=Value} pairs, similar to a
> +@samp{qfDllInfo} reply. The name, the segment offsets, or both may be
> +used to specify which DLL to unload, e.g.@:
> +@samp{unload:Name=@var{hexname}} or
> +@samp{unload:Name=@var{hexname},TextSeg=@var{textaddr}}. The entry
> +may end in @samp{,nop} if this library is still mapped, e.g.@: by
> +another open handle. @var{aa} should be @samp{05}, the trap signal.
> +
> +@item
> +If @var{n} is @samp{dll}, then the packet indicates that the loaded
> +DLLs have changed. @value{GDBN} should use @samp{qfDllInfo} to fetch
> +a new list of loaded libraries. @var{r} is ignored. @var{aa} should
> +be @samp{05}, the trap signal.
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.
> +Reply:
> +@table @samp
> +@item m Name=@var{hexname},TextSeg=@var{textaddr}@r{[},DataSeg=@var{dataaddr}@r{]}
> +A single loaded library. @var{hexname} is the name of the library,
> +as a hexadecimal sequence of ASCII characters. @var{textaddr} is the
> +load address for the text segment of the library. @var{dataaddr} is
> +the load address for the data segment of the library, if necessary.
> +If only @var{textaddr} is provided, the data segment will be relocated
> +by the same amount as the text segment.
> +
> +Other @samp{Key=Value} pairs may be added later to describe target
> +specific data.
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.
> +If the packet ends with @samp{;l} then no further @samp{qsDllInfo}
> +packet will be sent.
Perfect. Same trick as with qXfer.