From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21629 invoked by alias); 10 Nov 2003 22:10: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 21575 invoked from network); 10 Nov 2003 22:10:44 -0000 Received: from unknown (HELO palrel10.hp.com) (156.153.255.245) by sources.redhat.com with SMTP; 10 Nov 2003 22:10:44 -0000 Received: from hplms2.hpl.hp.com (hplms2.hpl.hp.com [15.0.152.33]) by palrel10.hp.com (Postfix) with ESMTP id BC5751C034CD; Mon, 10 Nov 2003 14:10: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 hAAMAgxf023986; Mon, 10 Nov 2003 14:10:42 -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 hAAMAgFO018764; Mon, 10 Nov 2003 14:10:42 -0800 Received: (from davidm@localhost) by napali.hpl.hp.com (8.12.3/8.12.3/Debian-6.6) id hAAMAf06018760; Mon, 10 Nov 2003 14:10:41 -0800 From: David Mosberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16304.3297.662733.250523@napali.hpl.hp.com> Date: Mon, 10 Nov 2003 22:10:00 -0000 To: Andrew Cagney Cc: davidm@hpl.hp.com, Andrew Cagney , Kevin Buettner , "J. Johnston" , gdb-patches@sources.redhat.com Subject: Re: RFA: ia64 portion of libunwind patch In-Reply-To: <3FAD7F01.2050407@gnu.org> 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> <3FAC2D03.8070607@redhat.com> <16300.12503.585501.180768@napali.hpl.hp.com> <3FAC33B3.2030403@redhat.com> <1031108001337.ZM18506@localhost.localdomain> <3FAC388A.10207@redhat.com> <16300.39298.323956.667764@napali.hpl.hp.com> <3FAD7F01.2050407@gnu.org> Reply-To: davidm@hpl.hp.com X-URL: http://www.hpl.hp.com/personal/David_Mosberger/ X-SW-Source: 2003-11/txt/msg00199.txt.bz2 >>>>> On Sat, 08 Nov 2003 18:40:49 -0500, Andrew Cagney said: Andrew> What I don't think "libunwind" should be doing is assuming Andrew> that most efficient way to obtain specific elements of that Andrew> unwind table is to read that table en-mass. Instead I think Andrew> "libunwind" be careful to only request the specific memory Andrew> locations that it needs - trust the client to supply the Andrew> requests in the most efficient way possible. That's good in some cases and bad in others. Based on gdb's needs, I certainly could believe that there are some cases where incremental reading would be faster. Perhaps a stronger argument for incremental reading would be if it actually simplified the glue code that gdb needs to talk to libunwind. I care a lot about making the glue code as simple as possible and anything we can do to help there is of interest to me. Andrew> I should note that this has come up before, GDB encountered Andrew> performance problems with a library that was trying to out Andrew> smart a memory read bottle neck by slurping ever increasing Andrew> chunks of unneeded memory. This made the performance Andrew> problem worse not better - it was the volume of data and not Andrew> the number of xfers that was the bottle neck. Andrew> If we look at GDB with its 128k of unwind data. At 14*28 Andrew> byte requests per unwind, it would take ~300 unwinds before Andrew> GDB was required to xfer 128k (yes I'm pushing the numbers a Andrew> little here, but then I'm also ignoring the very significant Andrew> locality of the searches). Oh, but you're ignoring the latency effects. N 1-byte transfers can easily be much slower than a single N-byte transfer. Andrew> Scary as it is, GDB's already got a requrest to feltch a Andrew> shared library image from the target's memory :-/. That kind of throws your speed argument out of the water, though, doesn't it? ;-) Andrew> Provided the remote target knows the address of the unwind Andrew> table, GDB should be able to find a way of getting it to Andrew> libunwind. OK, I still don't quite understand why this is a common and important scenario. It strikes me as a corner-case which _occasionally_ may be useful, but if that's true, a bit of extra latency doesn't seem like a huge deal. In any case, perhaps it is possible to add incremental reading support by stealing a bit from one of the members in the "unw_dyn_table_info". All we really need is a single bit to indicate whether the table-data should be fetched from remote-memory. I'll think about it some more. --david