From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18621 invoked by alias); 31 Oct 2003 19:25:15 -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 18614 invoked from network); 31 Oct 2003 19:25:15 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 31 Oct 2003 19:25:15 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id D1582800046; Fri, 31 Oct 2003 14:25:14 -0500 (EST) Message-ID: <3FA2B71A.3080905@redhat.com> Date: Fri, 31 Oct 2003 19:25:00 -0000 From: "J. Johnston" Organization: Red Hat Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Cc: Andrew Cagney , Kevin Buettner , davidm@hpl.hp.com Subject: Re: RFA: ia64 portion of libunwind patch Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00882.txt.bz2 David Mosberger has answered the questions below. I'd like to include him in the discussion from now on. -- Jeff J. -------- Original Message -------- >>>>> On Thu, 30 Oct 2003 14:18:20 -0500, "J. Johnston" said: Andrew> Can you expand a little here on how this function interacts Andrew> with libunwind? It is used by libunwind to access the unwind info. This is read-only data that part of the ELF image and (at least for ia64) is also mapped into the target space. Andrew> I can see that its reading in data, but is that data found Andrew> in the target's space? It could be found there. Andrew> If it is then the info should be pulled direct from the Andrew> target and the BFD/objfile should not be used. The relevant Andrew> target stratum can then re-direct the request to a local Andrew> file. I agree, it sounds like this would be a much cleaner way of doing it. Andrew> I'm also wondering if the unwind code (probably impossible I Andrew> know) could use a callback to request the memory rather than Andrew> require an entire buffer. 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. --david