From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5360 invoked by alias); 31 Oct 2003 21:36:11 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5353 invoked from network); 31 Oct 2003 21:36:10 -0000 Received: from unknown (HELO ns1.xcllnt.net) (209.128.86.226) by sources.redhat.com with SMTP; 31 Oct 2003 21:36:10 -0000 Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h9VLZqbe018414; Fri, 31 Oct 2003 13:35:52 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.10/8.12.10) with ESMTP id h9VLZqP9067558; Fri, 31 Oct 2003 13:35:52 -0800 (PST) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.10/8.12.10/Submit) id h9VLZp8O067557; Fri, 31 Oct 2003 13:35:51 -0800 (PST) (envelope-from marcel) Date: Fri, 31 Oct 2003 21:36:00 -0000 From: Marcel Moolenaar To: "J. Johnston" Cc: gdb-patches@sources.redhat.com, Andrew Cagney , Kevin Buettner , davidm@hpl.hp.com Subject: Re: RFA: ia64 portion of libunwind patch Message-ID: <20031031213551.GA67387@dhcp01.pn.xcllnt.net> References: <3FA2B71A.3080905@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FA2B71A.3080905@redhat.com> User-Agent: Mutt/1.5.4i X-SW-Source: 2003-10/txt/msg00889.txt.bz2 On Fri, Oct 31, 2003 at 02:25:14PM -0500, J. Johnston wrote: > > Andrew> I'm also wondering if the unwind code (probably impossible I > Andrew> know) could use a callback to request the memory rather than > Andrew> require an entire buffer. > > The way the libunwind interface works nowadays, the only buffering > that is strictly needed is for the unwind info of the procedure being > looked up (which usually has a size of the order of tens of bytes). > But this would require doing a binary search on the unwind-table in > the target space, which might be rather slow (there is one 24-byte > entry in this table per procedure). Thus, it might be easier (and > certainly faster) to buffer the unwind table inside gdb. Getting the unwind tables for remote targets can take a while if the load module is large and the communication is slow (say 9600 baud). Since libunwind already does its own caching, we may be better off not caching in gdb. This also works better with dynamic unwind information, which cannot be cached without some way of validating whether the cached information is still correct or not. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net