From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Richard Sandiford <rdsandiford@googlemail.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH 06/15] MIPS/GAS/test: Adjust LD for multi-target testing
Date: Mon, 18 Oct 2010 01:39:00 -0000 [thread overview]
Message-ID: <alpine.LFD.2.00.1010180157491.15889@eddie.linux-mips.org> (raw)
In-Reply-To: <87aammmle6.fsf@firetop.home>
On Sun, 10 Oct 2010, Richard Sandiford wrote:
> The patch seems to contain some parts that make the matching more strict
> and some that make it less so. The former look good, but I'm less sure
> about the latter. For example, with something like:
>
> [0-9a-f]+ <[^>]*> lw a0,(0|4096)\(at\)
> [ ]*[0-9a-f]+: [A-Z0-9_]*LO[A-Z0-9_]* \.data(\+0xfffff000)?
>
> the difference seems relatively important: on some targets the addend
> must be in-place, on some it mustn't be. It might make more sense
> to have separate dumps for the two cases. However, that sort of
> difference is probably picked up by other tests too, so the risk
> might not be great.
This is certainly strictier than the original that for the record was:
[0-9a-f]+ <[^>]*> lw a0,0\(at\)
[ ]*[0-9a-f]+: [A-Z0-9_]*LO[A-Z0-9_]* .data.*
(and obviously failed for ECOFF because of the different in-place addend).
I have actually weighed the strictness of the patterns used against
long-time maintenance effort and I think my proposal is a reasonable
compromise. The probability of the addend (the in-place one and/or one in
the relocation) being wrong exactly such that it would still match all the
patterns is minimal (which, under the appropriate Murphy's law, is
guaranteed to happen, I know; or does it only apply to the impossible? ;)
). Having a separate dump for ECOFF is OTOH guaranteed to leave it in
neglection since the moment I will have committed it. Having the dumps
combined gives a good chance the ECOFF variant of the testcases involved
will stay stay either in the working order or close to for a while.
As observed with some other changes made in this series, ECOFF testsuite
failures are mainly if not exclusively caused by bitrot in the testsuite
itself rather than from actual code of binutils malfunctioning.
Regrettably I found no way to avoid creating a couple of ECOFF-specific
dumps in this series, but for the reason stated I'd like to avoid them as
much as possible.
As a side note, I'd be more than happy to come up with a solution that
could let us make exact matches of addresses dumped without sacrificing
the ability to insert or delete pieces of test cases while keeping the
diffs applied to dumps readable. What I have in mind is an expression
that would match an address printed on the previous (or an earlier) line,
possibly offset by a constant specified in the dump. That would require
changes to the test framework more substantial than a small adjustment, so
while I'm keeping this enhancement in my mind, I don't feel like I have
resources available at hand (time, in particular) to dig into it.
> Also, how confident are we that the more relaxed tests are correct
> for ECOFF? You say:
>
> > 2. Consequently section alignment is requested at 4k so that offsets are
> > round and do not change for ECOFF when instructions are added or
> > removed (ECOFF seems to make data relocations relative to .text).
>
> but is that intentional?
I haven't investigated the way ECOFF relocations work and my knowledge of
the executable format consists of the notion that it exists. Someone has
added these trailing .* regexps though, presumably legitimately (I would
be ridiculous to assume I'm the only one sane, although sometimes my
confidence is weak :( ).
> The point here, and here:
>
> > 3. Missing "$" prefixes are added to the names of FP registers (shows how
> > frequently some of the targets are tested, hmm...).
>
> is precisely that mips*-ecoff has severely bitrotted from lack of
> active interest, so who knows how good the current output actually is?
> There's a danger in simply making the testsuite match what the current
> ECOFF assembler does.
These "$" prefixes were actually missing for ELF targets, specifically
mipstx39*-*-* (the only target setting ${gpr_ilocks}); being embedded
rather than workstation class devices, I wouldn't expect Toshiba chips in
any ECOFF systems.
> In a similar vein, the difference between endiannesses is something
> that could easily go wrong, but there are separate tests that should
> pick that up. I'm much more comfortable with the endianness bits.
We have this endianness leeway in many testcases. I think it's better to
have it than to hardcode endianness in the cases, making the the other
endianness completely untested. Again, it *might* be possible to improve
the test framework to dynamically select between alternatives, defined in
some way, based on the default target's endianness, but it looks all but
trivial to me.
> Overall the patch is improvement, so it's OK to apply despite
> the concerns above.
Applied, thanks. I think my changes are not of the kind that would
discourage further improvements.
Maciej
next prev parent reply other threads:[~2010-10-18 1:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-03 19:40 Maciej W. Rozycki
2010-10-10 9:45 ` Richard Sandiford
2010-10-18 1:39 ` Maciej W. Rozycki [this message]
2010-10-18 17:46 ` Maciej W. Rozycki
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=alpine.LFD.2.00.1010180157491.15889@eddie.linux-mips.org \
--to=macro@linux-mips.org \
--cc=binutils@sourceware.org \
--cc=rdsandiford@googlemail.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).