This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How to tell gdb about dlls using remote protocol

> X-Spam-Check-By:
> Date: Thu, 1 Feb 2007 09:53:11 -0800
> From: Joel Brobecker <>
> Content-Disposition: inline
> Mailing-List: contact; run by ezmlm
> Sender:
> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact for more information.
> X-UTwente-MailScanner: Found to be clean
> X-UTwente-MailScanner-From:
> X-Spam-Status: No
> X-XS4ALL-DNSBL-Checked: checked against DNS blacklists
> X-Virus-Scanned: by XS4ALL Virus Scanner
> X-XS4ALL-Spam: NO
> Envelope-To:
> X-UIDL: 1170352362._smtp.mxdrop39.85044,S=5181
> --vkogqOf2sHV7VnPd
> 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?
> Mark,
> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]