How to tell gdb about dlls using remote protocol

[Mark Kettenis]

> X-Spam-Check-By: sourceware.org
> Date: Thu, 1 Feb 2007 09:53:11 -0800
> From: Joel Brobecker <brobecker@adacore.com>
> Content-Disposition: inline
> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
> Sender: gdb-owner@sourceware.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: gdb-return-27623-m.m.kettenis=alumnus.utwente.nl@sourceware.org
> X-Spam-Status: No
> X-XS4ALL-DNSBL-Checked: mxdrop39.xs4all.nl checked 130.89.2.13 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: mark.kettenis@xs4all.nl
> 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.

Mark