From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9610 invoked by alias); 31 Oct 2003 22:55:45 -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 9603 invoked from network); 31 Oct 2003 22:55:44 -0000 Received: from unknown (HELO palrel13.hp.com) (156.153.255.238) by sources.redhat.com with SMTP; 31 Oct 2003 22:55:44 -0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by palrel13.hp.com (Postfix) with ESMTP id C67DB1C01AA3; Fri, 31 Oct 2003 14:55:43 -0800 (PST) Received: from napali.hpl.hp.com (napali.hpl.hp.com [15.4.89.123]) by hplms2.hpl.hp.com (8.12.10/8.12.10/HPL-PA Hub) with ESMTP id h9VMthRU003293; Fri, 31 Oct 2003 14:55:43 -0800 (PST) Received: from napali.hpl.hp.com (napali [127.0.0.1]) by napali.hpl.hp.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9VMthFO010557; Fri, 31 Oct 2003 14:55:43 -0800 Received: (from davidm@localhost) by napali.hpl.hp.com (8.12.3/8.12.3/Debian-6.6) id h9VMtgda010553; Fri, 31 Oct 2003 14:55:42 -0800 From: David Mosberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16290.59502.799536.383397@napali.hpl.hp.com> Date: Fri, 31 Oct 2003 22:55:00 -0000 To: Andrew Cagney Cc: "J. Johnston" , davidm@hpl.hp.com, gdb-patches@sources.redhat.com, Kevin Buettner Subject: Re: RFA: ia64 portion of libunwind patch In-Reply-To: <3FA2CA1B.7000502@redhat.com> References: <3FA2B71A.3080905@redhat.com> <3FA2CA1B.7000502@redhat.com> Reply-To: davidm@hpl.hp.com X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ X-SW-Source: 2003-10/txt/msg00896.txt.bz2 >>>>> On Fri, 31 Oct 2003 15:46:19 -0500, Andrew Cagney said: >> 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. Andrew> Given a PC, how is the table located? I see the change does Andrew> roughly: pc -> section -> objfile -> BFD -> unwind segment Andrew> -> paddr/size? That's about right. Andrew> (GDB appears to have a log2 (128k of unwind section / 24) = Andrew> ~14) I'm guessing that the binary search involves about 14 Andrew> fetches and provided they are serviced from a cache they Andrew> will be very efficient. Yup. --david