Re: Win32 gdbserver dll support.

[Pedro Alves <pedro_alves@portugalmail.pt>]

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