Win32 gdbserver dll support.

Win32 gdbserver dll support.

[Pedro Alves]

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

Re: Win32 gdbserver dll support.

[Pedro Alves]

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
> 

Re: Win32 gdbserver dll support.

[Daniel Jacobowitz]

On Thu, Apr 26, 2007 at 11:27:24PM +0100, Pedro Alves wrote:
> 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 ;)

Please wait at least a little bit :-)  I have a complete
implementation of this for gdb and gdbserver.  I just never got around
to posting it - but we were reminded of it last week and I've actually
got it on my work schedule to submit these bits in the next week or
two.

I don't understand why you're trying to use file operations to get a
link map, though.  I also have the GDB side of a DLL implementation; I
posted it to gdb@ in a discussion with Stephen Smith at the end of
last year, but that was an untested / unfinished port of my work from
an older GDB branch.

I'd been planning to write a gdbserver implementation of DLL events to
go with it, so that it could be tested (it was originally for a custom
SymbianOS stub).  Here's the docs - the patch in that message doesn't
apply, Stephen had to bang on it for a bit.  I did a bad job ripping
it out of my other tree.

  http://sourceware.org/ml/gdb/2006-12/msg00067.html

Anyway, could you see if the documented packets would suffice for you?
I can try to bump up getting this ported to mainline.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Win32 gdbserver dll support.

[Pedro Alves]

Daniel Jacobowitz escreveu:
> On Thu, Apr 26, 2007 at 11:27:24PM +0100, Pedro Alves wrote:
>> 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 ;)
> 
> Please wait at least a little bit :-)  

Done.  Thanks.

I have a complete
> implementation of this for gdb and gdbserver.  I just never got around
> to posting it - but we were reminded of it last week and I've actually
> got it on my work schedule to submit these bits in the next week or
> two.
> 
> I don't understand why you're trying to use file operations to get a
> link map, though.  

To read a /proc/<pid>/maps file, like this, present on Cygwin,
but would be generated on the fly for MinGW/WinCE:

eg, a running xterm:

 >cat /proc/1212/maps
00400000-00455000 rwxs 00401000 7883:7D87 14107871588017482856 \
    /usr/bin/xterm.exe
7C910000-7C9C6000 rw-p 7C923156 844E:63BD 1407374883610570 \
    /cygdrive/c/WINDOWS/system32/ntdll.dll
7C800000-7C901000 r-xs 7C80B5AE 844E:63BD 28991922601225566 \
   /cygdrive/c/WINDOWS/system32/kernel32.dll
10000000-100E1000 r-xs 10087B60 7883:7D87 7845553216729453710 \
   /usr/X11R6/bin/cygX11-6.dll
61000000-61200000 r-xs 61053CA0 7883:7D87 14949965846046300828 \
   /usr/bin/cygwin1.dll
77DA0000-77E4B000 r-xs 77DA70D4 844E:63BD 1407374883610592 \
    /cygdrive/c/WINDOWS/system32/ADVAPI32.DLL
77E50000-77EE1000 r-xs 77E56284 844E:63BD 1125899906900219 \
    /cygdrive/c/WINDOWS/system32/RPCRT4.dll
(...)

It happens to have all the info needed.  Load address (1st on the left),
and image name (last, on the right).

I also have the GDB side of a DLL implementation; I
> posted it to gdb@ in a discussion with Stephen Smith at the end of
> last year, but that was an untested / unfinished port of my work from
> an older GDB branch.
> 
> I'd been planning to write a gdbserver implementation of DLL events to
> go with it, so that it could be tested (it was originally for a custom
> SymbianOS stub).  Here's the docs - the patch in that message doesn't
> apply, Stephen had to bang on it for a bit.  I did a bad job ripping
> it out of my other tree.
> 
>   http://sourceware.org/ml/gdb/2006-12/msg00067.html
> 
> Anyway, could you see if the documented packets would suffice for you?
> I can try to bump up getting this ported to mainline.
> 


Eh, the infrun.c bits, look quite similar to what
I've done too.

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.
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 ?
As I tried saying in the beginning of the thread, my idea was
that gdb would always fetch all the loaded dlls, through reading
and parsing that maps file implemented in the solib-*.c for the
solib arch in case.  For that I splitted the win32 solib stuff
from win32-nat.c into solib-win32.c, which turned out to be
quite small.

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

Thanks!

Cheers,
Pedro Alves

Re: Win32 gdbserver dll support.

[Daniel Jacobowitz]

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

Re: Win32 gdbserver dll support.

[Daniel Jacobowitz]

On Sun, Apr 29, 2007 at 10:45:31PM -0400, Daniel Jacobowitz wrote:
> > I'll take a deeper look at the patch in a couple of days.
> 
> Thanks.  So will I.  Maybe I can simplify it further.

FYI, I'm still working on this.  I've got all of my existing code to
work with trunk at last.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Win32 gdbserver dll support.

[Pedro Alves]

Hi Daniel,

On 5/3/07, Daniel Jacobowitz <drow@false.org> wrote:
> On Sun, Apr 29, 2007 at 10:45:31PM -0400, Daniel Jacobowitz wrote:
> > > I'll take a deeper look at the patch in a couple of days.
> >
> > Thanks.  So will I.  Maybe I can simplify it further.
>
> FYI, I'm still working on this.  I've got all of my existing code to
> work with trunk at last.
>

Glad you're working on this, and was going to report tonight :)

I looked into it last night too.  I've got cygwin native working with
your solib-target.c, to get a feeling if it would be a good match.  It is.
There is just one case, that I bet you'll be looking into, which is
the relocate_section_addresses solib-target op.  Your implementation
was elf specific.  To get it up working as a fast prototype, I used
a method that wouldn't work for elf.

I stumbled on core dump support, dll loading.  Current win32-nat.c
reads the dlls
that were loaded in the core, on win32_current_sos, depending on core_bfd
being set.  Perhaps we need a new op somewhere, maybe in struct core_fns too.

Anyway, I'm writing this on a hurry.

Perhaps you would want to take a look at my changes, to get a better feeling
of what is needed for win32.  I'll get home in a few hours.

Cheers,
Pedro Alves

Re: Win32 gdbserver dll support.

[Daniel Jacobowitz]

On Thu, May 03, 2007 at 05:11:42PM +0100, Pedro Alves wrote:
> Glad you're working on this, and was going to report tonight :)
> 
> I looked into it last night too.  I've got cygwin native working with
> your solib-target.c, to get a feeling if it would be a good match.  It is.
> There is just one case, that I bet you'll be looking into, which is
> the relocate_section_addresses solib-target op.  Your implementation
> was elf specific.  To get it up working as a fast prototype, I used
> a method that wouldn't work for elf.

Yep.  I've been moving the ELF-specific bits into elfread.c for the
last hour.  For Windows this should be easy, since it looks like DLLs
are always relocated by a single offset; does Windows CE relocate text
and data by different amounts, or is there still a single image base?

> I stumbled on core dump support, dll loading.  Current win32-nat.c
> reads the dlls
> that were loaded in the core, on win32_current_sos, depending on core_bfd
> being set.  Perhaps we need a new op somewhere, maybe in struct core_fns too.

You're probably right; then corelow can implement the 
to_get_shared_libraries method.

> Perhaps you would want to take a look at my changes, to get a better feeling
> of what is needed for win32.  I'll get home in a few hours.

Yes please.  I'll try to combine all the pieces.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Win32 gdbserver dll support.

[Pedro Alves]

Daniel Jacobowitz wrote:
> 
> Yep.  I've been moving the ELF-specific bits into elfread.c for the
> last hour.  For Windows this should be easy, since it looks like DLLs
> are always relocated by a single offset; does Windows CE relocate text
> and data by different amounts, or is there still a single image base?
> 

Still a single image base.

> Yes please.  I'll try to combine all the pieces.
> 

Sent.

Many thanks for doing this.

Cheers,
Pedro Alves