This is the mail archive of the
mailing list for the GDB project.
Re: How to tell gdb about dlls using remote protocol
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: brobecker at adacore dot com
- Cc: Wiljan dot Derks at zonnet dot nl, gdb at sourceware dot org
- Date: Wed, 7 Feb 2007 23:14:27 +0100 (CET)
- Subject: Re: How to tell gdb about dlls using remote protocol
- References: <003f01c7457c$0f2d8090$9600000a@kamer> <20070131223113.GA15122@nevyn.them.org> <20070201175311.GG17864@adacore.com>
> X-Spam-Check-By: sourceware.org
> Date: Thu, 1 Feb 2007 09:53:11 -0800
> From: Joel Brobecker <firstname.lastname@example.org>
> Content-Disposition: inline
> Mailing-List: contact email@example.com; run by ezmlm
> Sender: firstname.lastname@example.org
> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information.
> X-UTwente-MailScanner: Found to be clean
> X-UTwente-MailScanner-From: email@example.com
> X-Spam-Status: No
> X-XS4ALL-DNSBL-Checked: mxdrop39.xs4all.nl checked 18.104.22.168 against DNS blacklists
> X-Virus-Scanned: by XS4ALL Virus Scanner
> X-XS4ALL-Spam-Score: -2.0 () DK_POLICY_SIGNSOME,RCVD_IN_NLWHITE
> X-XS4ALL-Spam: NO
> Envelope-To: firstname.lastname@example.org
> X-UIDL: 1170352362._smtp.mxdrop39.85044,S=5181
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Hi Daniel,
> > > The problem that I have run into, is that I can find no way to let gdb know
> > > what dll's are inside the
> > > debugee using the remote protocol.
> > >
> > > Does anyone know if there is a way to do this ?
> > There's no way to do this yet. If you look at the list archives for
> > the last several months, you'll see a patch (in the "GDB solib
> > interface" thread) that implements something which might help. But it
> > hasn't been finalized or committed yet (sorry Stephen - I just haven't
> > had time).
> This makes me wonder how well the debugger can work in certain
> situations like when backtracing from DLL code. If the debugger
> doesn't know where it is, then it's probably let to prologue analysis
> to do the unwinding. Except that it cannot determine where the prologue
> is... In that case, I see that the i386 unwinder assumes that the frame
> base can be deduced from the SP and the SP offset. Unfortunately,
> this SP offset can only be deduced from prologue analysis. Catch 22?
> What do you think of this (untested) patch? We we couldn't find
> the function start address, the safest seems to be relying on ebp.
I think this diff makes sense. However, I'm pretty sure there are
Linux systems out there where this will make things worse :(. In
particular, on kernels with a vsyscall page buit without the stub
shared library for that page, this change will systematically skip a
frame. And that frame is quite crucial since it is the frame for the
libc system call stub, so it will be hard for a user to find out in
what system call the program is blocked on.
I have no idea though how many people are still runing those kernels.
That number might be very low enough for us not to care.