From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15244 invoked by alias); 29 Oct 2003 18:43:13 -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 15237 invoked from network); 29 Oct 2003 18:43:12 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 29 Oct 2003 18:43:12 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 1EE92800376; Wed, 29 Oct 2003 13:43:12 -0500 (EST) Message-ID: <3FA00A3F.4020909@redhat.com> Date: Wed, 29 Oct 2003 18:43: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: Kevin Buettner Cc: Daniel Jacobowitz , Marcel Moolenaar , 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> <20031029012833.GA11070@nevyn.them.org> <1031029044805.ZM4842@localhost.localdomain> In-Reply-To: <1031029044805.ZM4842@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00842.txt.bz2 Kevin Buettner wrote: > 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. > Sorry, I understand now. > 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...) > The kernel unwind table is kmalloc'd. The syscall makes a copy of it. > >>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...) > Andrew has suggested I look at to_read_partial. -- Jeff J.