From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12510 invoked by alias); 7 Nov 2003 23:38:43 -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 12494 invoked from network); 7 Nov 2003 23:38:43 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 7 Nov 2003 23:38:43 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 532952B8F; Fri, 7 Nov 2003 18:38:43 -0500 (EST) Message-ID: <3FAC2D03.8070607@redhat.com> Date: Fri, 07 Nov 2003 23:38: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: "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> <3FAC12D3.2070207@redhat.com> <16300.8192.489647.740612@napali.hpl.hp.com> <3FAC2454.2030009@redhat.com> <16300.9949.513264.716812@napali.hpl.hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-11/txt/msg00143.txt.bz2 > On Fri, 07 Nov 2003 18:01:40 -0500, Andrew Cagney said: > > > Andrew> Is fetching the table elements via a function, rather than a > Andrew> direct access, really that significant an overhead? > > Is allocating a scratch buffer in gdb really such a big issue? > It's very late for proposing libunwind API changes. Draging that entire buffer (128k in the case of a program like GDB) across the remote link is going to raise a few eyebrows so a careful examination is justified. If that search is so critical can the algorithm be made more efficient? If it isn't then, per my suggestion, have the code use the memory method as a fallback. Andrew