Re: Remove code handling old ARM aliases from GDB

[Hans-Peter Nilsson <hp@bitrange.com>]

On Thu, 5 May 2011, Joseph S. Myers wrote:
> On Thu, 5 May 2011, Hans-Peter Nilsson wrote:
>
> > On Thu, 5 May 2011, Joseph S. Myers wrote:
> > > On Thu, 5 May 2011, Hans-Peter Nilsson wrote:
> > >
> > > > > -if { [istarget xscale*-*-*] } {
> > > > > +if { [istarget arm*-*-*] } {
> > >
> > > > How did you test these changes?
> > >
> > > I considered them sufficiently obviously syntactically correct not to need
> > > testing.
> >
> > It might have seemed like that at the time, but obviously it
> > wasn't so.
>
> Well, it was *syntactically correct*, as shown by the tests running in
> your log rather than hitting a Tcl syntax error.

Please, we're not talking about Tcl syntax.

> > > I don't call that breaking testing; I call that exposing bugs (whether in
> > > the simulator or testsuite) that were previously hidden by the use of an
> > > obsolete target triplet name.
> >
> > arm-elf passed before and does not anymore after those changes.
>
> "arm-elf" is not a testcase.

I'm not sure what you mean, but "arm-elf passed" was a
contraction for "when running the sim tests for the arm-elf
target, they all passed", which should be obvious from the
context.

> A testsuite regression is when a test assertion fails before and passes
> after a patch.  A test assertion corresponds to particular text that may
> appear after "PASS: " or "FAIL: " in the .sum file (for a properly
> functioning DejaGnu testsuite, a slightly looser definition may be
> appropriate for GDB at present).  A failure of a test that was not run
> before the patch is not a regression.

I did not say that a specific test regressed; I didn't even
mention the word regression.

But now that you mention it, the end result of running the
test-suite for the arm-elf is certainly a regression from before
those changes.

> > That's breaking testing.
>
> No, breaking testing would be introducing a syntax error so that tests
> that previously run stop running or run incorrectly.  Output with FAILs in
> it isn't broken, it simply gives information about what works and what
> doesn't.  If a FAIL replaced a PASS that would be a regression, not
> breaking testing, but that isn't the case here either.

Splitting of hairs, choice of words.  I guess we have to
disagree on the words, but I'm sure we can agree that running
the tests does exit with an error after, but didn't before your
changes.

As having introduced this, you're on the hook to investigate and
rectify.  Another option to those I mentioned is to xfail or
kfailing the failing tests.  Please.

brgds, H-P