From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12132 invoked by alias); 31 Oct 2003 20:46:26 -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 12122 invoked from network); 31 Oct 2003 20:46:22 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 31 Oct 2003 20:46:22 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 0B1EB2B89; Fri, 31 Oct 2003 15:46:20 -0500 (EST) Message-ID: <3FA2CA1B.7000502@redhat.com> Date: Fri, 31 Oct 2003 20:46: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: "J. Johnston" , davidm@hpl.hp.com Cc: gdb-patches@sources.redhat.com, Andrew Cagney , Kevin Buettner Subject: Re: RFA: ia64 portion of libunwind patch References: <3FA2B71A.3080905@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00886.txt.bz2 > 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. Ok. The target vector consists of a number of stratum. When a memory request is sent to the target it is responsible (note, minus bugs) for servicing the request using the most applicable stratum. For instance, given a core file, modified memory sections are supplied by the process/corefile stratum, while read-only sections are supplied by the file/executable stratum. > 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. As they say, make it work correctly, then make it work fast :-) If target i/o gets to be a problem, we [gdb] get to fix the target stack. > 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. Given a PC, how is the table located? I see the change does roughly: pc -> section -> objfile -> BFD -> unwind segment -> paddr/size? (could it look up the BFD's .IA_64.unwind_* sections instead?) I guess initially, it could just use the paddr/size to pull the memory from "current_target"? I suspect though that long term a memory request callback will prove more effective - it would avoid locking GDB into a model that requires it to cache full and contigous unwind sections. Using a back of envelope caculation (GDB appears to have a log2 (128k of unwind section / 24) = ~14) I'm guessing that the binary search involves about 14 fetches and provided they are serviced from a cache they will be very efficient. Andrew