From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32498 invoked by alias); 24 Oct 2003 21:53:03 -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 32490 invoked from network); 24 Oct 2003 21:53:01 -0000 Received: from unknown (HELO ns1.xcllnt.net) (209.128.86.226) by sources.redhat.com with SMTP; 24 Oct 2003 21:53:01 -0000 Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h9OLqsbe066680; Fri, 24 Oct 2003 14:52:54 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.10/8.12.10) with ESMTP id h9OLqsLd076072; Fri, 24 Oct 2003 14:52:54 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.10/8.12.10/Submit) id h9OLqsu0076071; Fri, 24 Oct 2003 14:52:54 -0700 (PDT) (envelope-from marcel) Date: Fri, 24 Oct 2003 21:53:00 -0000 From: Marcel Moolenaar To: Kevin Buettner Cc: "J. Johnston" , ac131313@redhat.com, gdb-patches@sources.redhat.com Subject: Re: RFA: ia64 portion of libunwind patch Message-ID: <20031024215254.GA75962@dhcp01.pn.xcllnt.net> References: <3F986E31.8050201@redhat.com> <1031024175718.ZM3475@localhost.localdomain> <3F996D88.9060505@redhat.com> <1031024185625.ZM9827@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1031024185625.ZM9827@localhost.localdomain> User-Agent: Mutt/1.5.4i X-SW-Source: 2003-10/txt/msg00756.txt.bz2 On Fri, Oct 24, 2003 at 11:56:25AM -0700, Kevin Buettner wrote: > > > > >>+#ifdef HAVE_LIBUNWIND_IA64_H > > >>+ > > >>+# ifndef __NR_getunwind > > >>+# define __NR_getunwind 1215 > > >>+# endif > > > > > > Is this part still needed? > > > > Not if we include > > I would prefer to see included -- but not in > ia64-tdep.c. This include 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. Isn't the unwind library linked into gdb and using callbacks for memory reads and obtaining register values so that we can use the existing protocol commands to extract information from the inferior? Hmmm... this raises the question how the unwind library knows about dynamic unwind descriptors in remote targets... > Also, apparently, there'll be some FreeBSD patches for IA-64 coming > down the pike. FreeBSD, if it chooses to use the libunwind library, > will need to implement its own version of ia64_getunwind(). Yes, I intend to have an unwind library on FreeBSD. I'm happy to see that support is being added. Standardizing on David's unwind library is possible now that it has the MIT license. Unfortunately it depends on many GNU build tools (autoconf, automake, libtool etc). This may be a reason for me to use an API compatible alternative as I expect it to be a PITA to import libunwind into FreeBSD and have it play nice with the BSD make infrastructure. Also, my first attempts to port it to FreeBSD weren't as successful as I hoped it would be. There's a certain amount of Linuxism in it that didn't (near) trivially map to FreeBSDisms. Anyway: I'll be talking to David when the time comes :-) -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net