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

[Mark Kettenis <mark dot kettenis at xs4all dot nl>]

> Date: Wed, 9 May 2007 16:16:27 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> Not all platforms work this way.  The exceptions I'm looking at
> recently are DLL-based platforms: Windows and SymbianOS.  Both use an
> OS-level loader instead.  You have to query the OS to get the list
> of libraries, and the OS provides event notification directly instead
> of via a magic breakpoint.  We can't poke and prod at the OS directly
> during remote debugging, so to implement DLL support for these
> platforms I extended the remote protocol.

Can we please avoid the term DLL for this stuff?  That's just a
particular implementation of shared objects/libraries.  This
functionality is generally usable, and not specific to Windows.

> The additions are three new stop replies for the "T" packet to report
> events (load, unload, and dll for "something more complicated than
> just a load or unload") and two new packets (qfDllInfo and qsDllInfo)
> to query the current state.  Detailed documentation is below and the
> patch is attached.
> 
> This patch introduces a new solib_ops vector in solib-target.c.  This
> vector is target driven; it maintains a list based on the query packet
> and event notices, instead of looking through memory.
> 
> I have tested this code on SymbianOS, Cygwin, and MinGW32.  Pedro
> Alves has tested a slightly earlier version on Windows CE (and wrote
> the gdbserver bits I used to test it on Windows - thanks!).
> 
> What do you think, Kevin especially?  I'm not entirely thrilled with
> the way this interacts with other solib_ops vectors, but I'm not
> unhappy with it either.

I think this diff needs to be split up.  I looked at it twice now, but
I don't see how the bits are related, and the changes to infrun.c make
me very nervous.

Mark