From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21846 invoked by alias); 7 Feb 2007 22:14:40 -0000 Received: (qmail 21837 invoked by uid 22791); 7 Feb 2007 22:14:40 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 07 Feb 2007 22:14:33 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.0/8.14.0) with ESMTP id l17MERkg028834; Wed, 7 Feb 2007 23:14:27 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.0/8.14.0/Submit) id l17MER45023107; Wed, 7 Feb 2007 23:14:27 +0100 (CET) Date: Wed, 07 Feb 2007 22:14:00 -0000 Message-Id: <200702072214.l17MER45023107@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: brobecker@adacore.com CC: Wiljan.Derks@zonnet.nl, gdb@sourceware.org In-reply-to: <20070201175311.GG17864@adacore.com> (message from Joel Brobecker on Thu, 1 Feb 2007 09:53:11 -0800) 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> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-02/txt/msg00044.txt.bz2 > X-Spam-Check-By: sourceware.org > Date: Thu, 1 Feb 2007 09:53:11 -0800 > From: Joel Brobecker > 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