From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2505 invoked by alias); 7 Nov 2003 21:47:00 -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 2477 invoked from network); 7 Nov 2003 21:46:59 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 7 Nov 2003 21:46:59 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C34952B8F; Fri, 7 Nov 2003 16:46:59 -0500 (EST) Message-ID: <3FAC12D3.2070207@redhat.com> Date: Fri, 07 Nov 2003 21:47:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: davidm@hpl.hp.com Cc: Andrew Cagney , "J. Johnston" , gdb-patches@sources.redhat.com, Kevin Buettner Subject: Re: RFA: ia64 portion of libunwind patch References: <3FA2B71A.3080905@redhat.com> <3FA2CA1B.7000502@redhat.com> <16290.59502.799536.383397@napali.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-11/txt/msg00137.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. Would it be possible to define the interface so that, when dip->u.ti.table_data is NULL, the code just fetches values from memory using the memory callbacks? i.e., don't require GDB to fetch the entire table but instead fetch the bits that are needed. Andrew