Re: Win32 gdbserver dll support.

[Pedro Alves <pedro_alves@portugalmail.pt>]

Pedro Alves escreveu:
> 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?
> 

I actually bit the bullet and I'm investigating/implementing
remote open/close/read/write/lseek.  It seems to be enough for
now.  If there are any objections, please speak up, you'll
probably save me "a couple" of hours ;)


> 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
>