Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Luis Machado <lgustavo@codesourcery.com>, Yao Qi <qiyaoltc@gmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH/RFC] Refactor gdb.reverse/insn-reverse.c
Date: Wed, 25 Jan 2017 17:44:00 -0000	[thread overview]
Message-ID: <aa7d56ef-7d6e-1c6d-3c7b-8ce39dabef02@redhat.com> (raw)
In-Reply-To: <f0007a17-032a-bc9c-3caa-8ca94bd71a18@codesourcery.com>

On 01/25/2017 04:50 PM, Luis Machado wrote:
> On 01/25/2017 10:10 AM, Yao Qi wrote:
>> On 17-01-16 13:10:54, Luis Machado wrote:
>>> I've broken up the main file into other files with arch-specific bits
>>> (insn-support-<arch>.c). The main file will hold the generic pieces
>>> that will
>>> take care of calling the tests.
>>>
>>
>> It is reasonable to me.  Can we name arch-specific files as
>> insn-reverse-<arch>.c?
>>
> 
> Thanks for the review.
> 
> Would you reconsider this? I named it insn-support-<arch>.c because we
> already know this is a reverse debugging test (from gdb.reverse) and we
> are really testing instruction support. I'm fine either way though, and
> just wanted to add a little bit more context in the name.

My 2c nit.

"support" doesn't sound ideal to me.  By that logic,
every test in the testsuite is testing gdb's support of some
feature, so "support" is redundant?

When I see a file named "support", I think it's some base/foundation
(==support) framework.  Is that the case here?  I had understood
that the "base" is in insn-reverse.c instead?  Or are the
insn-support-<arch>.c files meant to be shared between multiple
test cases, thus they'll be providing "support" for a multitude
of random tests?  insn-reverse-<arch>.c at least gave a hint
that the files are all related to insn-reverse.c.

Also, if "reverse" is redundant in "insn-reverse-<arch>.c", then
it is also redundant in "insn-reverse.c" too, so you should be arguing
for renaming "insn-reverse.c|exp" -> "insn-support.c|exp" too, which
would preserve the similarity of the names between the driver
file + the arch files.

Thanks,
Pedro Alves


  reply	other threads:[~2017-01-25 17:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-16 19:11 Luis Machado
2017-01-24 16:20 ` Luis Machado
2017-01-25 16:10 ` Yao Qi
2017-01-25 16:50   ` Luis Machado
2017-01-25 17:44     ` Pedro Alves [this message]
2017-01-25 18:11       ` Luis Machado
2017-01-25 22:28         ` Yao Qi
2017-01-26 16:39           ` Luis Machado
2017-01-26 16:54             ` Luis Machado

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=aa7d56ef-7d6e-1c6d-3c7b-8ce39dabef02@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=lgustavo@codesourcery.com \
    --cc=qiyaoltc@gmail.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