public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: "Jose E. Marchesi" <jose.marchesi@oracle.com>
Cc: binutils@sourceware.org
Subject: Re: [COMMITTED 2/3] gas: BPF pseudo-c syntax tests
Date: Thu, 27 Apr 2023 10:26:13 +0200	[thread overview]
Message-ID: <3ce08588-8065-473a-2ff8-d2c412406cbb@suse.com> (raw)
In-Reply-To: <20230426173123.24564-2-jose.marchesi@oracle.com>

On 26.04.2023 19:31, Jose E. Marchesi via Binutils wrote:
> --- a/gas/ChangeLog
> +++ b/gas/ChangeLog
> @@ -1,3 +1,23 @@
> +2023-04-20  Guillermo E. Martinez  <guillermo.e.martinez@oracle.com>
> +
> +	PR gas/29728
> +	* testsuite/gas/all/assign-bad-recursive.d: Skip test in bpf-*
> +	targets.
> +	* testsuite/gas/all/eqv-dot.d: Likewise.
> +	* testsuite/gas/all/gas.exp: Skip other assignment tests in bpf-*.

I view doing such as problematic. Looking at what patch 3 documents,
the uses of " = " are pretty limited, and ones not naming a register
on the lhs (or, for store forms, on the rhs) ought to be fine to
retain their meaning. Sadly there isn't an easy way to specify target-
specific flags, or else I'd be inclined to suggest that you have an
option to suppress recognition of the C-like syntax (which may be a
good idea anyway, as people might be using constructs like the ones
used in the testcases you now disable) and use it here and below.

In any event, ...

> --- a/gas/testsuite/gas/all/eqv-dot.d
> +++ b/gas/testsuite/gas/all/eqv-dot.d
> @@ -2,7 +2,7 @@
>  #name: eqv involving dot
>  # bfin doesn't support 'symbol = expression'
>  # tic30 and tic4x have 4 octets per byte, tic54x has 2 octets per byte
> -#notarget: bfin-*-* *c30-*-* *c4x-*-* *c54x-*-*
> +#notarget: bfin-*-* *c30-*-* *c4x-*-* *c54x-*-* *bpf-*-*

... at least in cases where there already are justifying comments, new
additions of exceptions shouldn't go uncommented.

> --- a/gas/testsuite/gas/bpf/alu-be.d
> +++ b/gas/testsuite/gas/bpf/alu-be.d
> @@ -1,5 +1,6 @@
>  #as: --EB
>  #source: alu.s
> +#source: alu-pseudoc.s
>  #objdump: -dr
>  #name: eBPF ALU64 instructions, big endian

I may of course be reading binutils-common.exp's run_dump_test wrong,
but is this having the intended effect of assembling each of the files
once and checking objdump output for each of them? It looks to me as
if only the assembling step would be performed for both, which I don't
think is what is wanted.

> --- a/gas/testsuite/gas/macros/macros.exp
> +++ b/gas/testsuite/gas/macros/macros.exp
> @@ -82,6 +82,7 @@ switch -glob $target_triplet {
>      rl78-*-* { }
>      rx-*-* { }
>      vax-*-* { }
> +    bpf-*-* { }
>      default { run_list_test dot "-alm" }
>  }

How is this test affected by your changes? It consists of only labels
and directives afaics, so insn syntax expectations shouldn't matter
at all.

Jan

  reply	other threads:[~2023-04-27  8:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-26 17:31 [COMMITTED 1/3] gas: support for the BPF pseudo-c assembly syntax Jose E. Marchesi
2023-04-26 17:31 ` [COMMITTED 2/3] gas: BPF pseudo-c syntax tests Jose E. Marchesi
2023-04-27  8:26   ` Jan Beulich [this message]
2023-04-27  9:59     ` Jose E. Marchesi
2023-04-27 10:05       ` Jan Beulich
2023-04-27 18:07         ` Jose E. Marchesi
2023-04-28  6:10           ` Jan Beulich
2023-04-26 17:31 ` [COMMITTED 3/3] gas: documentation for the BPF pseudo-c asm syntax Jose E. Marchesi

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=3ce08588-8065-473a-2ff8-d2c412406cbb@suse.com \
    --to=jbeulich@suse.com \
    --cc=binutils@sourceware.org \
    --cc=jose.marchesi@oracle.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).