From: Marcel Moolenaar <marcel@xcllnt.net>
To: Kevin Buettner <kevinb@redhat.com>
Cc: "J. Johnston" <jjohnstn@redhat.com>,
ac131313@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: RFA: ia64 portion of libunwind patch
Date: Fri, 24 Oct 2003 21:53:00 -0000 [thread overview]
Message-ID: <20031024215254.GA75962@dhcp01.pn.xcllnt.net> (raw)
In-Reply-To: <1031024185625.ZM9827@localhost.localdomain>
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 <sys/syscall.h>
>
> I would prefer to see <sys/syscall.h> 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
next prev parent reply other threads:[~2003-10-24 21:53 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-24 0:11 J. Johnston
2003-10-24 17:57 ` Kevin Buettner
2003-10-24 18:20 ` J. Johnston
2003-10-24 18:56 ` Kevin Buettner
2003-10-24 21:53 ` Marcel Moolenaar [this message]
2003-10-24 23:58 ` Kevin Buettner
2003-10-28 23:53 ` J. Johnston
2003-10-29 1:28 ` Daniel Jacobowitz
2003-10-29 4:48 ` Kevin Buettner
2003-10-29 18:43 ` J. Johnston
2003-10-29 22:48 ` Andrew Cagney
2003-11-04 19:09 ` J. Johnston
2003-11-04 20:48 ` Kevin Buettner
2003-11-06 17:21 ` RFA: ia64 portion of libunwind patch updated J. Johnston
2003-11-14 21:24 ` J. Johnston
2003-11-17 17:01 ` Kevin Buettner
2003-11-17 17:03 ` Kevin Buettner
2003-11-17 17:05 ` Kevin Buettner
2003-11-17 21:40 ` J. Johnston
2003-11-17 22:32 ` Marcel Moolenaar
2003-11-06 20:03 ` [commit] Fix two xfer partial bugs; Was; RFA: ia64 portion of libunwind patch Andrew Cagney
2003-11-06 20:12 ` J. Johnston
2003-11-06 22:32 ` [patch/rfc] Add child_to_xfer_partial; Was: " Andrew Cagney
2003-11-06 22:47 ` J. Johnston
2003-11-07 21:40 ` Andrew Cagney
2003-11-07 1:04 ` Kevin Buettner
2003-11-14 0:26 ` RFA: " J. Johnston
2003-11-14 1:17 ` Kevin Buettner
2003-11-14 20:49 ` J. Johnston
2003-10-29 23:28 ` Andrew Cagney
2003-11-02 20:39 ` Elena Zannoni
2003-10-29 15:18 ` Andrew Cagney
2003-10-31 19:25 J. Johnston
2003-10-31 20:46 ` Andrew Cagney
2003-10-31 22:55 ` David Mosberger
2003-11-07 21:47 ` Andrew Cagney
2003-11-07 22:43 ` David Mosberger
2003-11-07 23:01 ` Andrew Cagney
2003-11-07 23:12 ` David Mosberger
2003-11-07 23:38 ` Andrew Cagney
2003-11-07 23:55 ` David Mosberger
2003-11-08 0:07 ` Andrew Cagney
2003-11-08 0:13 ` Kevin Buettner
2003-11-08 0:27 ` Andrew Cagney
2003-11-08 7:21 ` David Mosberger
2003-11-09 0:13 ` Andrew Cagney
2003-11-10 22:10 ` David Mosberger
2003-11-10 22:43 ` Andrew Cagney
2003-11-10 23:01 ` David Mosberger
2003-11-26 0:11 ` David Mosberger
2003-12-04 2:15 ` David Mosberger
2003-12-04 3:15 ` Kevin Buettner
2003-12-04 23:57 ` J. Johnston
2003-12-05 0:39 ` David Mosberger
2003-12-10 20:58 ` J. Johnston
2003-12-10 22:15 ` David Mosberger
2003-12-12 22:25 ` Kevin Buettner
[not found] ` <davidm@napali.hpl.hp.com>
2003-12-13 4:01 ` Kevin Buettner
2003-11-09 1:34 ` Marcel Moolenaar
2003-11-10 21:54 ` David Mosberger
2003-11-10 23:18 ` Marcel Moolenaar
2003-10-31 21:36 ` Marcel Moolenaar
2003-10-31 23:00 ` David Mosberger
2003-10-31 23:42 ` Andrew Cagney
2003-10-31 23:59 ` David Mosberger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031024215254.GA75962@dhcp01.pn.xcllnt.net \
--to=marcel@xcllnt.net \
--cc=ac131313@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jjohnstn@redhat.com \
--cc=kevinb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox