From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30692 invoked by alias); 1 Feb 2007 17:52:21 -0000 Received: (qmail 30683 invoked by uid 22791); 1 Feb 2007 17:52:20 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 01 Feb 2007 17:52:12 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 902B348CE2E; Thu, 1 Feb 2007 12:52:10 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25256-01; Thu, 1 Feb 2007 12:52:10 -0500 (EST) Received: from takamaka.act-europe.fr (unknown [70.71.0.212]) by nile.gnat.com (Postfix) with ESMTP id 3609B48CDE8; Thu, 1 Feb 2007 12:52:10 -0500 (EST) Received: by takamaka.act-europe.fr (Postfix, from userid 1000) id E65CB34C099; Thu, 1 Feb 2007 09:53:11 -0800 (PST) Date: Thu, 01 Feb 2007 17:52:00 -0000 From: Joel Brobecker To: Wiljan Derks , gdb@sourceware.org, Mark Kettenis Subject: Re: How to tell gdb about dlls using remote protocol Message-ID: <20070201175311.GG17864@adacore.com> References: <003f01c7457c$0f2d8090$9600000a@kamer> <20070131223113.GA15122@nevyn.them.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: <20070131223113.GA15122@nevyn.them.org> User-Agent: Mutt/1.4.2.2i 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/msg00007.txt.bz2 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1143 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. -- Joel --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="i386-tdep.c.diff" Content-length: 717 Index: i386-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/i386-tdep.c,v retrieving revision 1.230 diff -u -p -r1.230 i386-tdep.c --- i386-tdep.c 29 Jan 2007 17:31:06 -0000 1.230 +++ i386-tdep.c 1 Feb 2007 17:50:51 -0000 @@ -979,6 +979,12 @@ i386_frame_cache (struct frame_info *nex /* This will be added back below. */ cache->saved_regs[I386_EIP_REGNUM] -= cache->base; } + else if (cache->pc == 0) + { + /* We couldn't determine the function start address, bla + bla bla. */ + cache->saved_regs[I386_EBP_REGNUM] = 0; + } else { frame_unwind_register (next_frame, I386_ESP_REGNUM, buf); --vkogqOf2sHV7VnPd--