Win32 gdbserver dll support.

["Pedro Alves" <pedro_alves at portugalmail dot pt>]

Hi guys,

I'm looking into adding dll support to gdbserver, primarily
for WinCE, but Cygwin would also benefit, of course.

I realize that solib support for svr4 targets works without
special remote protocol support, because you can get at the
link maps by just fiddling with the inferior memory, and
putting breakpoints in the special places on the loader.

There are some targets, where that isn't possible, like
Windows, where the dynamic loader is part of the OS, or
targets where the link map must the read from the /proc
file system.

Current native Windows support (win32-nat.c), autoloads
the dlls symbols immediately when a LOAD_DLL_DEBUG event
arrives, bypassing a bit the normal solib.c interface.
I have a patch for that, that makes win32 fetch the
loaded dlls every time through current_sos, and making
win32_relocate_section_address to its job.

It looks like that what is needed is a way to
somehow ask gdbserver for a virtual link map, perhaps in
textual form, that could be parsed by gdb much like one
parses the map on /proc/ targets.  That would also fit
nicely for those targets, except they would return a
copy of the real link map file, whereas Win32 would return
a file generated on the fly.  Eg.  If AIX got gdbserver
support, it could call
target_ops->fetch_inferior_file ("/proc/<pid>/map") in
build_so_list_from_mapfile, and do the same parsing as it
already does.  The fetch_inferior_file
target_op could have a default implementation of reading
a local file so native debugging would work unaffected.

Another alternative, would be to add
TARGET_WAITKIND_LOADED state to the remote protocol
(an 'L' packet perhaps), and somehow
marshall the lm_info data with the state change notification,
which is specific for each different target_so_ops.
I don't like this much, since there are targets where
you would find yourself in marshalling pointers, meaning
that probably it would be more invasive, then needs be.
It may be more efficient, since we wouldn't fetch the whole
solibs list everytime, but build it on the gdb size.  On the
other hand, fetching the map in one go probably isn't
that inefficient.

Adding full support for remote opening,
seeking, stating, etc, is certainly doable, but perhaps
a bit out of scope for simplicity of the remote protocol?

Adding a simple 'char* read_remote_file (const char* filename)'
in target_ops, that reads the whole file at once would
suffice for the problem at hands.  I'm ignoring buffering
problems on purpose, since map files tend to be small.
I would have to add TARGET_WAITKIND_LOADED state to
the remote protocol for dll loading/unloadind notification,
but without passing any data to gdb,
and then gdb would fetch the dlls list with
current_sos + fetch_remote_file in reaction to the
state change.  infrun.c:handle_inferior_event already does that,
but it is guarded on '#ifdef SOLIB_ADD'.  It would be a matter
of exposing it always.

Any ideas?  Perhaps something simpler I'm not seing?

Daniel, I once saw somewhere on the archives that
you have once made win32 dlls work with gdbserver.  I can't
find that pointer now, though.  Do you have at hand that
implementation, or remember the interface you used/implemented?

Cheers,
Pedro Alves