This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc / remote protocol] Remote shared library events
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: drow at false dot org
- Cc: gdb-patches at sourceware dot org
- Date: Thu, 10 May 2007 23:34:51 +0200 (CEST)
- Subject: Re: [rfc / remote protocol] Remote shared library events
- References: <20070509201627.GA23422@caradoc.them.org>
> 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