Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Marcel Moolenaar <marcel@xcllnt.net>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] New port: ia64-*-freebsd
Date: Fri, 15 Jul 2005 00:01:00 -0000	[thread overview]
Message-ID: <20050715000144.GB21620@nevyn.them.org> (raw)
In-Reply-To: <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


  parent reply	other threads:[~2005-07-15  0:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-05 19:52 Marcel Moolenaar
2005-07-06 17:24 ` Followup: " Marcel Moolenaar
2005-07-15  0:01 ` Daniel Jacobowitz [this message]
2005-07-15  2:08   ` Marcel Moolenaar
2005-07-15  2:16     ` Daniel Jacobowitz
2005-07-15 18:20       ` Marcel Moolenaar
2005-07-24 21:26         ` Daniel Jacobowitz
2005-07-25 17:32           ` Marcel Moolenaar
2005-07-25 17:36             ` Daniel Jacobowitz
2005-07-25 17:58               ` Marcel Moolenaar
2005-07-25 19:34                 ` Mark Kettenis
2005-07-25 20:41                   ` Marcel Moolenaar

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=20050715000144.GB21620@nevyn.them.org \
    --to=drow@false.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=marcel@xcllnt.net \
    /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