public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Thomas Koenig <tkoenig@netcologne.de>
Cc: binutils@sourceware.org
Subject: Re: [patch, gas, documentation] Some additional testsuite info
Date: Tue, 2 May 2023 08:33:34 +0200	[thread overview]
Message-ID: <52f243bf-40d8-e863-b3a5-a8339d6b74ff@suse.com> (raw)
In-Reply-To: <541a3fba-3b07-d4e3-f913-f10d7163a59e@netcologne.de>

On 30.04.2023 12:16, Thomas Koenig via Binutils wrote:
> here's some additional info on the gas testsuite.  I also took the
> liberty to delete the "kind of lame" comment, which is not really
> appropriate any more, at least not for the architectures which
> were added in the last few decades.

Up-front remark: Non-inlined patches are hard to comment upon.

You refer to "the main binutils directory", which is ambiguous next
to "the main gas directory". Itym the top-level directory there
(and not e.g. the binutils/ one being a sibling of gas/).

The reference to "a @code{nop} instruction" is ambiguous, too, I'm
afraid: There's no such requirement (anymore) if you mean to refer
to an instruction truly named "nop" and not taking any operands.
Many architectures don't have such. But this has been overcome by
the introduction of the .nop directive, which merely requires the
arch to have some insn which is "no operation" (which might e.g.
be ORin zero into a register). I'm pretty sure almost all
architectures will have such. I'm also quite sure though that there
are old tests which are yet to be converted ...

You move but otherwise retain the sentence regarding the need to
change expectations when objdump output style changes. I think
this should be relaxed at least as slightly as saying "may need to
be" instead of "must". Generally you'll find that more modern tests
write expectations in suitably relaxed regexp-s such that quite a
few possible layout/style changes wouldn't require adjustments. And
I think if doc is adjusted in this area anyway, it should recommend
to write expectations as tight as necessary (for the purpose of
the test), but as relaxed as possible.

Jan

      reply	other threads:[~2023-05-02  6:33 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-30 10:16 Thomas Koenig
2023-05-02  6:33 ` Jan Beulich [this message]

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=52f243bf-40d8-e863-b3a5-a8339d6b74ff@suse.com \
    --to=jbeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=tkoenig@netcologne.de \
    /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).