From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22956 invoked by alias); 29 Oct 2003 04:48:38 -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 22622 invoked from network); 29 Oct 2003 04:48:16 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 29 Oct 2003 04:48:16 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h9T4mEM10255 for ; Tue, 28 Oct 2003 23:48:14 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h9T4mD613869; Tue, 28 Oct 2003 23:48:13 -0500 Received: from localhost.localdomain (vpn50-2.rdu.redhat.com [172.16.50.2]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h9T4mBju003920; Tue, 28 Oct 2003 23:48:11 -0500 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h9T4m5Y04843; Tue, 28 Oct 2003 21:48:05 -0700 Date: Wed, 29 Oct 2003 04:48:00 -0000 From: Kevin Buettner Message-Id: <1031029044805.ZM4842@localhost.localdomain> In-Reply-To: Daniel Jacobowitz "Re: RFA: ia64 portion of libunwind patch" (Oct 28, 8:28pm) References: <3F986E31.8050201@redhat.com> <1031024175718.ZM3475@localhost.localdomain> <3F996D88.9060505@redhat.com> <1031024185625.ZM9827@localhost.localdomain> <3F9F0180.2010702@redhat.com> <20031029012833.GA11070@nevyn.them.org> To: Daniel Jacobowitz , "J. Johnston" Subject: Re: RFA: ia64 portion of libunwind patch Cc: Kevin Buettner , Marcel Moolenaar , ac131313@redhat.com, gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00832.txt.bz2 On Oct 28, 8:28pm, Daniel Jacobowitz wrote: > On Tue, Oct 28, 2003 at 06:53:36PM -0500, J. Johnston wrote: > > I have addressed your comments below. The bfd stuff (map_segment, > > map_info) has been replaced by a simple call to bfd_bread(). I have moved > > the getunwind syscall stuff into ia64-linux-tdep.c and I access it via the > > gdbarch_tdep structure. > > Nothing which involves a syscall is acceptable in a tdep file. That's > what the t means - target support. > > Move it to the -nat file. Yes, I agree with Daniel. Earlier, I had said: ... and the code for ia64_getunwind() will have to go in ia64-linux-nat.c. Presumably, if a remote target wanted to use the unwind library, there'd need to be some remote protocol modifications. I also asked the following questions: Hmm... thinking about this some more, I'd like to know why a syscall is required. Is there any way this functionality could be implemented in an OS independent fashion? I'm guessing that there's kernel state that the unwinder needs to be made aware of and that it won't be possible to implement ia64_getunwind() in an OS independent manner. (I'd like someone to verify this though...) > I don't know how you should integrate it with the gdbarch tdep. If my speculation above is correct, I don't think the gdbarch tdep ought to be used for accessing ia64_getunwind(). This sort of smells like something that belongs in the target vector. (Since we need different mechanisms for the remote and native cases.) But, since this functionality is highly ia64-centric, I'd really hate to pollute the target vector with such a method. The only approach that comes to mind (at the moment) is something similar to the native_find_global_pointer hook in ia64-tdep.c. (AIX/rs6000 has something similar.) Note though that this kind of hook doesn't help with the native / remote problem. Again, it'd be really, *really*, REALLY nice if we could come up with an OS independent way of determining the necessary information. E.g. Is there any way to do memory reads to obtain the necessary information? (I'm guessing not, but it doesn't hurt to ask...) Kevin