From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15083 invoked by alias); 9 Nov 2003 00:13:34 -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 14298 invoked from network); 9 Nov 2003 00:13:08 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 9 Nov 2003 00:13:08 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id D19302B90; Sat, 8 Nov 2003 18:40:49 -0500 (EST) Message-ID: <3FAD7F01.2050407@gnu.org> Date: Sun, 09 Nov 2003 00:13: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 , Kevin Buettner , "J. Johnston" , gdb-patches@sources.redhat.com 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> <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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-11/txt/msg00159.txt.bz2 > Andrew> "at least not locally". The unwind info can always be found > Andrew> in the target's memory. > > Andrew> There are two choices here: - make the interface more remote > Andrew> friendly - just ignore the issue until someone complains > > Can you make it so that the local ELF image is used _when_ it's > available? "libunwind" should assume that GDB will fill each memory request using the most efficient [correct] source available. One potential source being the local ELF image. If this isn't happening then GDB has something to fix (significantly, "libunwind" should resist the temptation to work around any such problems). What I don't think "libunwind" should be doing is assuming that most efficient way to obtain specific elements of that unwind table is to read that table en-mass. Instead I think "libunwind" be careful to only request the specific memory locations that it needs - trust the client to supply the requests in the most efficient way possible. I should note that this has come up before, GDB encountered performance problems with a library that was trying to out smart a memory read bottle neck by slurping ever increasing chunks of unneeded memory. This made the performance problem worse not better - it was the volume of data and not the number of xfers that was the bottle neck. If we look at GDB with its 128k of unwind data. At 14*28 byte requests per unwind, it would take ~300 unwinds before GDB was required to xfer 128k (yes I'm pushing the numbers a little here, but then I'm also ignoring the very significant locality of the searches). > I personally never used gdb without specifying an > executable file (I'm not even sure how that works), so I guess I'm > willing to wait until someone complains (note that it's not as easy as > simply setting table_data to NULL, because there would be no way to > calculate the address of the unwind-table entry, so I'm not sure what > you want could be done without breaking the existing API). Scary as it is, GDB's already got a requrest to feltch a shared library image from the target's memory :-/. Provided the remote target knows the address of the unwind table, GDB should be able to find a way of getting it to libunwind. > Andrew> Hmm, a good question to ask is "how cross debug friendly" is > Andrew> libunwind.? If its anything like libthread-db then this > Andrew> discussion is mute. > > I don't know what the issue with libthread-db is, but libunwind is > designed to be cross-debug friendly. It's a feature that gets > regularly tested, e.g., as part of libunwind built into HP's ia64 > simulator (which runs fine on x86 linux, for example). In theory, > libunwind also support multiple unwind targets in the same binary, but > this hasn't been tested much so far (but I also have no reason to > believe that it doesn't work). "all of the above", this is very good news! Andrew