This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Win32 gdbserver dll support.
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