Re: Win32 gdbserver dll support.

[Daniel Jacobowitz <drow@false.org>]

On Fri, Apr 27, 2007 at 12:34:00AM +0100, Pedro Alves wrote:
> I was trying to avoid doing what you've done with
> solib-target.c the same solib-*.c when native or remote debugging.
> That is, keeping the remote/native vs 'solib target' separate.

That's the bit I liked least too.  I don't remember exactly how it
worked, but my intention was to use the same solib module for local or
remote debugging; we could switch Windows to reuse solib-target.c (if
it was simpler that way).

The problem is that there are two solib models.  One, SysV's, does not
require any target specific operations.  That's a property of the
architecture.  The other, which Windows et al use, is (sort of)
independent of the architecture, but requires information from the
target.

The best I could think of was this, which lets the architecture defer
to the target.

> Are you sure that textSeg+dataSeg is enough?  That is the lm_info
> marshaling stuff I was talking about.  By reading a remote file,
> you let the solib-*.c implementation handle that.  Ok, you can
> pass name/value pairs, but then you have to add support for
> the new pairs on solib-target.c ?

Text and data segment addresses were enough for me.  I think they
would suffice for Windows, too.  But I'm not sure; the way it worked
on SymbianOS was that GDB ended up loading ELF files rather than the
target-format DLLs, and loading DLLs might impose some different
requirements.  If it's not enough, maybe we could use the architecture
methods to specialize solib-target.c without cluttering it; it could
be taught to keep track of arbitrary name/value pairs without knowing
what they were.  Or maybe there's a better design entirely.

I decided to add the load and unload events, even though they
complicated things a bit, because they're the most common case.  On
GNU/Linux the number of loaded libraries is usually relatively small.
On SymbianOS, it's not small - in fact it's mammoth.  There's usually
about fifty DLLs, and I was using a serial connection to the target.
So, slow's the word.

> I'll take a deeper look at the patch in a couple of days.

Thanks.  So will I.  Maybe I can simplify it further.

-- 
Daniel Jacobowitz
CodeSourcery