From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29486 invoked by alias); 29 Oct 2003 23:28:18 -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 29474 invoked from network); 29 Oct 2003 23:28:13 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 29 Oct 2003 23:28:13 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 530842B89; Wed, 29 Oct 2003 18:28:07 -0500 (EST) Message-ID: <3FA04D07.4050409@redhat.com> Date: Wed, 29 Oct 2003 23:28: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" Cc: Kevin Buettner , ac131313@redhat.com, gdb-patches@sources.redhat.com Subject: Re: RFA: ia64 portion of libunwind patch References: <3F986E31.8050201@redhat.com> <1031024175718.ZM3475@localhost.localdomain> <3F996D88.9060505@redhat.com> <1031024185625.ZM9827@localhost.localdomain> <3F9F0180.2010702@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00855.txt.bz2 Jeff, Can you expand a little here on how this function interacts with libunwind? I can see that its reading in data, but is that data found in the target's space? If it is then the info should be pulled direct from the target and the BFD/objfile should not be used. The relevant target stratum can then re-direct the request to a local file. I'm also wondering if the unwind code (probably impossible I know) could use a callback to request the memory rather than require an entire buffer. Hence the question. Andrew > +static int > +ia64_find_proc_info_x (unw_addr_space_t as, unw_word_t ip, unw_proc_info_t *pi, > + int need_unwind_info, void *arg) > +{ > + struct obj_section *sec = find_pc_section (ip); > + unw_dyn_info_t di; > + int ret; > + void *buf = NULL; > + > + if (!sec) > + { > + /* XXX This only works if the host and the target architecture are > + both ia64 and if the have (more or less) the same kernel > + version. */ > + if (get_kernel_table (ip, &di) < 0) > + return -UNW_ENOINFO; > + } > + else > + { > + ret = ia64_find_unwind_table (sec->objfile, ip, &di, &buf); > + if (ret < 0) > + return ret; > + } > + > + if (gdbarch_debug >= 1) > + fprintf_unfiltered (gdb_stdlog, "acquire_unwind_info: %lx -> " > + "(name=`%s',segbase=%lx,start=%lx,end=%lx,gp=%lx," > + "length=%lu,data=%p)\n", ip, (char *)di.u.ti.name_ptr, > + di.u.ti.segbase, di.start_ip, di.end_ip, > + di.gp, di.u.ti.table_len, di.u.ti.table_data); > + > + ret = libunwind_search_unwind_table (&as, ip, &di, pi, need_unwind_info, arg); > + > + /* We no longer need the dyn info storage so free it. */ > + xfree (buf); > + > + return ret; > +} > +