This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] New port: ia64-*-freebsd
- From: Daniel Jacobowitz <drow at false dot org>
- To: Marcel Moolenaar <marcel at xcllnt dot net>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 14 Jul 2005 20:01:44 -0400
- Subject: Re: [PATCH] New port: ia64-*-freebsd
- References: <20050705195104.GA1584@ns1.xcllnt.net>
I don't know anything about ia64, or much about FreeBSD, so I will
refrain from a thorough review. You'll need Kevin or Jeff to look over
it eventually (see MAINTAINERS). I have a bunch of comments about the
patch anyway, mostly dealing with the bits I couldn't make sense of - I
just wanted to do my part against the patch sitting unread for
months...
On Tue, Jul 05, 2005 at 12:51:04PM -0700, Marcel Moolenaar wrote:
> Gang,
>
> It took a while, but the legal preconditions have recently been
> met and I'm delighted to present you with the long awaited port
> of GDB to FreeBSD/ia64.
It's not very useful as a single jumbo patch - especially since you
didn't explain any of what it was doing.
You added bits to the remote protocol; those must be documented in the
manual (and, generally, discussed beforehand). Are there any stubs
which use them?
The comment on TARGET_OBJECT_DIRTY says "see ia64-tdep.c", which has
basically no comments explaining what it does, or why it is necessary
for FreeBSD when it isn't for GNU/Linux.
NATIVE_XFER_DIRTY is not necessary; the BSDs all use target vector
inheritance now as far as I know, so you can override it that way.
Similarly tm-fbsd.h is not necessary any more.
The corelow.c implementation of TARGET_OBJECT_DIRTY looks pretty
sketchy for target-independent code.
You have a lot of non-GNUish formatting issues - mostly the pesky
spacing rules.
The BFD bits need to go separately to the binutils@ list.
> There are some fixes that aren't exactly related to this port,
> but which I ran into and kept. It's probably better to commit
> those seperately, but I leave that up to the group.
Our preference is to do this sort of thing separately to simplify
review.
--
Daniel Jacobowitz
CodeSourcery, LLC