Re: [rfc / remote protocol] Remote shared library events

[Jim Blandy <jimb@codesourcery.com>]

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.