Re: Remove code handling old ARM aliases from GDB

["Joseph S. Myers" <joseph@codesourcery.com>]

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.

> > 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.

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.

> 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.

> Any other definition falls prey to
> "latent bugs" weaseling.

The simulator bugs exposed weren't latent since the simulator probably had 
those bugs for years.  So far as there were testsuite bugs (the tests not 
running) those were *fixed* by the patch.

I consider the situation here to be exactly the same as if I'd added 
target-independent tests to the GDB testsuite for a feature that should 
work on all targets but that would require target-specific work for most 
targets to make it work properly.  Such tests would, of course, expose 
bugs in various targets, but it would be up to those interested in 
improving results for each target to fix them there; I don't think there's 
any expectation that such new tests will pass everywhere.  (An example of 
potential new tests that would have such an issue would be tests for how 
GDB handles argument passing and return involving complex numbers; that 
needs ABI support for each target, and very few GDB targets have such ABI 
support that actually corresponds to what GCC does.)  I think enabling 
tests that were wrongly disabled is just like adding new tests - if 
someone fixing them is unclear about the semantics of instructions being 
tested, I'll try to advise on specific questions, just as I would on 
questions about the hypothetical tests for complex number ABIs.

-- 
Joseph S. Myers
joseph@codesourcery.com