public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Carl Love <cel@us.ibm.com>
Cc: Joel Brobecker <brobecker@adacore.com>,
	will schmidt <will_schmidt@vnet.ibm.com>,
	gdb-patches@sourceware.org,
	Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
	Tulio Magno <tuliom@linux.ibm.com>,
	Rogerio Alves <rogealve@br.ibm.com>
Subject: Re: [PATCH 1/2  Version 6] Add recording support for the ISA 3.1 Powerpc instructions
Date: Tue, 26 Apr 2022 11:05:46 -0700	[thread overview]
Message-ID: <Ymg0ekLi/gzGlMqb@adacore.com> (raw)
In-Reply-To: <806f06b987bdab9da6babc14f296d6944b220d68.camel@us.ibm.com>

> Thanks for the additional comments.  Given that we are not under any
> timeline to get this patch done and the changes are very minor I think
> it is better to just get it right the first time rather than have to
> come back ad fix it up later.  The changes are all localized as well.

That's a great attitude to have.

For large patches, it can have a bit of a perverse effect, though,
which is related to how code review is done for GDB (email-based).
So, to review a new iteration of a patch I already reviewed before,
when the patch is large, I tend to go fish in the archives the
previous iteration, and do a diff between previous and new. Easy
enough, but it requires a bit of time to do so. If I trust a person
enough to follow up, or when things are very minor, I tend to let
the patch through, and ask that the corrections be done as a followup
patch. It's true that this means two patches instead of one, so this
could be seen as a real downside -- but the upside is that the minor
updates are sent for review on their own, and very often, reviewing
just that update patch will be trivial, and therefore the chances
of it being reviewed are much higher in my experience.

I was able to take a bit of time today to review the new version,
though, and this version looks good to me. So you can go ahead
and push to master.

Thanks again.

> I have made the changes to the header comment for the function
> ppc_record_ACC_fpscr() to clairfy what the function does as well as to
> use the capitalization to indicate the value.  The parameter "at" was
> also changed to "entry" to make it clearer we are selecting one of the
> possible AT entries to be recorded.  Finally, argument save_fpscr was
> changed to a boolean thus eliminating the #defines for RECORD_FPSCR and
> DO_NOT_RECORD_FPSCR.  Fortunately, the changes are all at the beginning
> of the patch making it easy to find.
> 
> As always, the patch was retested to make sure I didn't break anything.
> Please let me know if the additional changes are acceptable.  Thanks.
-- 
Joel

  reply	other threads:[~2022-04-26 18:05 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-04 19:46 [PATCH 0/2] " Carl Love
2022-03-04 19:52 ` [PATCH 1/2] " Carl Love
2022-03-06 11:53   ` Joel Brobecker
2022-04-12 17:09     ` [PATCH 1/2 Version 2] " Carl Love
2022-04-12 21:50       ` will schmidt
2022-04-13 17:26         ` [PATCH 1/2 Version 3] " Carl Love
2022-04-17 16:23           ` Joel Brobecker
2022-04-18 19:21             ` [PATCH 1/2 Version 5] " Carl Love
2022-04-22 19:49               ` [PATCH 1/2 Version 5 Ping] " Carl Love
2022-04-24 16:50               ` [PATCH 1/2 Version 5] " Joel Brobecker
2022-04-25 15:58                 ` [PATCH 1/2 Version 6] " Carl Love
2022-04-26 18:05                   ` Joel Brobecker [this message]
2022-03-04 19:53 ` [PATCH 2/2] " Carl Love
2022-03-06 12:42   ` Joel Brobecker
2022-04-12 17:09     ` [PATCH 2/2 Version 2] " Carl Love
2022-04-13 14:12       ` will schmidt
2022-04-13 21:38         ` [PATCH 2/2 Version 3] " Carl Love
2022-04-14 13:05           ` Pedro Alves
2022-04-14 20:20             ` [PATCH 2/2 Version 4] " Carl Love
2022-04-14 20:43               ` Carl Love
2022-04-17 16:48                 ` Joel Brobecker
2022-04-18 19:21                   ` [PATCH 2/2 Version 5] " Carl Love
2022-04-22 19:47                     ` [PATCH 2/2 Version 5 PING] " Carl Love
2022-04-24 16:56                     ` [PATCH 2/2 Version 5] " Joel Brobecker
2022-04-12 17:09 ` [PATCH 0/2 Version 2] " Carl Love

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=Ymg0ekLi/gzGlMqb@adacore.com \
    --to=brobecker@adacore.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=cel@us.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=rogealve@br.ibm.com \
    --cc=tuliom@linux.ibm.com \
    --cc=will_schmidt@vnet.ibm.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).