This is the mail archive of the
mailing list for the GDB project.
Re: Win32 gdbserver dll support.
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 :-)
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
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:
00400000-00455000 rwxs 00401000 7883:7D87 14107871588017482856 \
7C910000-7C9C6000 rw-p 7C923156 844E:63BD 1407374883610570 \
7C800000-7C901000 r-xs 7C80B5AE 844E:63BD 28991922601225566 \
10000000-100E1000 r-xs 10087B60 7883:7D87 7845553216729453710 \
61000000-61200000 r-xs 61053CA0 7883:7D87 14949965846046300828 \
77DA0000-77E4B000 r-xs 77DA70D4 844E:63BD 1407374883610592 \
77E50000-77EE1000 r-xs 77E56284 844E:63BD 1125899906900219 \
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.
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
I'll take a deeper look at the patch in a couple of days.