From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28983 invoked by alias); 9 Nov 2003 01:34:49 -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 28976 invoked from network); 9 Nov 2003 01:34:49 -0000 Received: from unknown (HELO ns1.xcllnt.net) (209.128.86.226) by sources.redhat.com with SMTP; 9 Nov 2003 01:34:49 -0000 Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id hA91YNbe082425; Sat, 8 Nov 2003 17:34:23 -0800 (PST) (envelope-from marcel@piii.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.10/8.12.10) with ESMTP id hA91YNEQ069957; Sat, 8 Nov 2003 17:34:23 -0800 (PST) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.10/8.12.10/Submit) id hA91YMbc069944; Sat, 8 Nov 2003 17:34:22 -0800 (PST) (envelope-from marcel) Date: Sun, 09 Nov 2003 01:34:00 -0000 From: Marcel Moolenaar 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 Message-ID: <20031109013421.GA742@athlon.pn.xcllnt.net> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16300.9949.513264.716812@napali.hpl.hp.com> User-Agent: Mutt/1.5.4i X-SW-Source: 2003-11/txt/msg00161.txt.bz2 On Fri, Nov 07, 2003 at 03:12:29PM -0800, David Mosberger wrote: > >>>>> 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. I think it's very early to have it nailed down. Despite ones efforts to create a clean system, there are always assumptions underlying the code, including the API. I think it's in the best interest of libunwind if the developers (yes, you David :-) remain sensitive and open minded about the how well libunwind interfaces with or integrates into code that has a need for unwinding. Just something to think about, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net