Re: [commit] Deprecate remaining STREQ uses

Re: [commit] Deprecate remaining STREQ uses

[Michael Elizabeth Chastain]

eli> Since your proposal for deprecating counts minor releases, would it
eli> be enough to request a run for every such release?
mec> In my opinion, no.
eli> Why not?

Known regressions still go months before fixing.  And I don't mean
"months until the elusive bug can be duplicate"; I mean "months after I
file a PR with a simple test case and a pointer to the exact patch where
gdb broke".

Then consider how much worse this would be if I did one run per release
instead of several runs per week.

eli> Isn't it better to start deprecating only if we know that some code
eli> specific to a platform is broken by a certain change to GDB?
mec> Again, in my opinion, no.
eli> Again, why not?

Because nobody knows what change is going to break what platform.

And I'm getting tired of this conversation because I don't see any
constructive action coming out of it.  I'm going to continue my
aggressive QA campaign.  When I bump into someone, such as I've bumped
into David Anglin or you, my attitude is going to be "well, what can you
contribute to support the platform?"

Michael C

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Mon, 15 Dec 2003 01:22:30 -0500 (EST)
> From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
> 
> eli> Since your proposal for deprecating counts minor releases, would it
> eli> be enough to request a run for every such release?
> mec> In my opinion, no.
> eli> Why not?
> 
> Known regressions still go months before fixing.  And I don't mean
> "months until the elusive bug can be duplicate"; I mean "months after I
> file a PR with a simple test case and a pointer to the exact patch where
> gdb broke".
> 
> Then consider how much worse this would be if I did one run per release
> instead of several runs per week.

I agree that your suggestion will probably leave us with less bugs.
But I'm concerned that we could inadvertently spill the baby, if we
assume that any port that hasn't seen official testing does not work
and should be obsoleted.

> eli> Isn't it better to start deprecating only if we know that some code
> eli> specific to a platform is broken by a certain change to GDB?
> mec> Again, in my opinion, no.
> eli> Again, why not?
> 
> Because nobody knows what change is going to break what platform.

I think quite a few changes are known to break platforms for which a
replacement for a deprecated interface was not submitted.

> And I'm getting tired of this conversation because I don't see any
> constructive action coming out of it.

I'm sorry I took your time; I thought this issue was important enough
to be discussed at some length.

The constructive action that could come out of this, in my view, is if
we agree that hasty removal of support for platforms is potentially
destructive and should be used with great caution.

What about others: am I the only one who thinks we shouldn't be
obsoleting platforms hastily for lack of officially-certified testing?

> I'm going to continue my
> aggressive QA campaign.  When I bump into someone, such as I've bumped
> into David Anglin or you, my attitude is going to be "well, what can you
> contribute to support the platform?"

My comment to this is that we should sometimes think about users, not
only developers.  Being overly harsh to the users by removing support
for their platforms too quickly is something I think we should avoid.

Re: [commit] Deprecate remaining STREQ uses

[Daniel Jacobowitz]

On Mon, Dec 15, 2003 at 08:41:13AM +0200, Eli Zaretskii wrote:
> I agree that your suggestion will probably leave us with less bugs.
> But I'm concerned that we could inadvertently spill the baby, if we
> assume that any port that hasn't seen official testing does not work
> and should be obsoleted.

...

> The constructive action that could come out of this, in my view, is if
> we agree that hasty removal of support for platforms is potentially
> destructive and should be used with great caution.
> 
> What about others: am I the only one who thinks we shouldn't be
> obsoleting platforms hastily for lack of officially-certified testing?

This isn't a new issue, and it's not one with easy answers.  I also
think that Michael's stance is a little too harsh - good for an ideal
world, where we had more resources than we do (despite his absolutely
heroic efforts), but...

I am more interested in the removal of _unmaintained_ targets than in
the removal of _untested_ targets.  Normally these coincide; if they
don't for DJGPP then that's not a major problem to me.  We have a
couple of targets whose maintainers we haven't heard from in a while,
but they are likely to still work.  Looking at the list the only ones
I'm immediately worried about are d10v, mcore, mn10300, ns32k, v850,
vax.  Some of the others (like m32r) have seen a lot of activity.

I'd be terrified about sparc if Mark hadn't started to overhaul it.  I
remain worried about Solaris specifically.  We get a lot of Solaris
bug reports that go unanswered.

> My comment to this is that we should sometimes think about users, not
> only developers.  Being overly harsh to the users by removing support
> for their platforms too quickly is something I think we should avoid.

The alternative is finding that the platform hasn't actually worked in
three releases.

By the way, is there any reason DJGPP couldn't be tested in Bochs,
qemu, vmware, plex86, or some other new system emulator I haven't heard
of yet?  With qemu I suspect you could even make that scriptable, but
it would take some serious hacking - use the qemu console like a telnet
session.  Now that would be cool.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Mon, 15 Dec 2003 10:51:11 -0500
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> By the way, is there any reason DJGPP couldn't be tested in Bochs,
> qemu, vmware, plex86, or some other new system emulator I haven't heard
> of yet?

I don't know about these emulators.  In general, if they can run
DOS/Windows code and still support async subprocesses to the degree
that `expect' runs, then yes.

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

>> Date: Mon, 15 Dec 2003 10:51:11 -0500
>> From: Daniel Jacobowitz <drow@mvista.com>
>> 
>> By the way, is there any reason DJGPP couldn't be tested in Bochs,
>> qemu, vmware, plex86, or some other new system emulator I haven't heard
>> of yet?
> 
> 
> I don't know about these emulators.  In general, if they can run
> DOS/Windows code and still support async subprocesses to the degree
> that `expect' runs, then yes.

I don't think it is worth the effort.  I think djgpp using dejagnu's 
remote host code would be a bigger return but even then I'm backing away 
from the idea :-)

Michael, look at djgpp this way:

- i386 architecture
very well tested and (currently at least) where all the bugs are

- i386 @&^$(*^@#$*& coff
not so well tested :-(  we (as a group) need to find a way of testing 
this as a cross platform :-/  I think it is were the future bugs will 
be.  Would testing a *-*-pe platform help with this (arm comes to mind)?

- djgpp nat code
not so well tested, but hardly matters.  break main/run should tell us 
that that part of the code is still live.

So of the above, only the coff symbol reader is a real risk.

As for eliminating code, we're about done with architectures.  target 
vectors and natives will (and should be) next in the hot seat, but 
there, at least for a first pass flushing anything obviously dead (as I 
did to MIPS recently) will get us well along the path.

Also note that we can never draw a simple straight line here.  DJGPP, 
for instance, is, or at least was, considered an important system so 
some rule bending (which often translates into me doing the work no one 
else is willing to) is in order.

enjoy,
Andrew

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Wed, 31 Dec 2003 14:48:30 -0500
> From: Andrew Cagney <cagney@gnu.org>
> 
> So of the above, only the coff symbol reader is a real risk.

FWIW, I agree with that assessment.

Re: [commit] Deprecate remaining STREQ uses

[Michael Elizabeth Chastain]

I learned on hp-ux, and Eli learned on djgpp, that there is also
a risk from bit rot in imported code such as gdb/readline and gdb/intl.
It does not take much work to maintain these but we have to do
"break main; run" on more hosts more often.

> Also note that we can never draw a simple straight line here.  DJGPP, 
> for instance, is, or at least was, considered an important system so 
> some rule bending (which often translates into me doing the work no one 
> else is willing to) is in order.

Okay.

Michael C

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Wed, 31 Dec 2003 14:56:04 -0500 (EST)
> From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
> 
> I learned on hp-ux, and Eli learned on djgpp, that there is also
> a risk from bit rot in imported code such as gdb/readline and gdb/intl.
> It does not take much work to maintain these but we have to do
> "break main; run" on more hosts more often.

Indeed.

Note that one way to run the DJGPP port easily on GNU/Linux is via
DOSEmu.  (Building it should be possible with cross tools, so even
easier.)

Re: [commit] Deprecate remaining STREQ uses

[Michael Elizabeth Chastain]

drow> I am more interested in the removal of _unmaintained_ targets than in
drow> the removal of _untested_ targets.  Normally these coincide ...

Well, the natural thing to do is to take the intersection of
everybody's criteria.

We can also lobby each other to change our criteria but that has
limited results at the cost of lots of email.

Michael C

Re: [commit] Deprecate remaining STREQ uses

[Michael Elizabeth Chastain]

Hi Eli,

> However, running the script once a month (on the then-latest snapshot,
> I presume) is not something that I can afford, and I don't see anyone
> else stepping forward to do that for me.

If you can't commit 1-2 hours per month to test djgpp gdb, how are you
going to respond to bug reports and patches?  What's going to happen
when it bit rots and stops building?

I think you should reconsider whether you have the resources to be a
maintainer for djgpp gdb.

> Since your proposal for deprecating counts minor releases, would it
> be enough to request a run for every such release?

In my opinion, no.

> Isn't it better to start deprecating only if we know that some code
> specific to a platform is broken by a certain change to GDB?

Again, in my opinion, no.

The official gdb definition of "supported" is "gdb builds and break main;
run" works.  Personally, I think that's lame.  However, what we have
right now is a situation where we aren't even working to that standard.

Michael C

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Sun, 14 Dec 2003 11:02:24 -0500 (EST)
> From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
> 
> > However, running the script once a month (on the then-latest snapshot,
> > I presume) is not something that I can afford, and I don't see anyone
> > else stepping forward to do that for me.
> 
> If you can't commit 1-2 hours per month to test djgpp gdb, how are you
> going to respond to bug reports and patches?

It isn't 1-2 hours, unfortunately.  More like a full day.

> What's going to happen when it bit rots and stops building?
> 
> I think you should reconsider whether you have the resources to be a
> maintainer for djgpp gdb.

No one seems to be stepping forward, and I haven't seen patches
submitted for quite some time, anyway.  So it doesn't seem it will
make any difference.

That said, feel free to fire me.

> > Since your proposal for deprecating counts minor releases, would it
> > be enough to request a run for every such release?
> 
> In my opinion, no.

Why not?

> > Isn't it better to start deprecating only if we know that some code
> > specific to a platform is broken by a certain change to GDB?
> 
> Again, in my opinion, no.

Again, why not?

Re: [commit] Deprecate remaining STREQ uses

[Michael Elizabeth Chastain]

Hi Eli,

> There's something I'm probably missing here: who is responsible for
> ``submitting test results'' for a platform?

Anybody who wants gdb HEAD to keep working on that platform.

That's usually the maintainer, but someone doesn't have to take on the
whole job of maintaining a platform to submit test results for it.

> To make this more concrete, I don't think I (or anyone else) have ever
> sent test results for the DJGPP (a.k.a. go32) target, for which I
> alone am responsible.  Does that mean you will promote starting to
> deprecate it VSN?

Yes, but not "VSN" because I am up to my neck in other bugs.

And then you will come back and say "go32 does not support running the
test suite".  And then I will say: okay, fine, can you build gdb on
go32?  Can you do "break main"?  Can you do a backtrace?  Can you print
registers?  Can you print a local variable?  Can you set a watchpoint?
Can you call a function with a double precision argument?

Can you put all that in a script and post the results to gdb-testers once a
month?

If nobody does those things for a platform, then I want to obsolete the
platform.  If anybody is actually using the platform then they can
either stay with their current gdb forever, or they can find someone to
help out with the QA process on gdb HEAD for that platform.

Michael C

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Sun, 14 Dec 2003 03:25:30 -0500 (EST)
> From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
> 
> And then you will come back and say "go32 does not support running the
> test suite".  And then I will say: okay, fine, can you build gdb on
> go32?  Can you do "break main"?  Can you do a backtrace?  Can you print
> registers?  Can you print a local variable?  Can you set a watchpoint?
> Can you call a function with a double precision argument?
> 
> Can you put all that in a script and post the results to gdb-testers once a
> month?

It should be relatively easy to produce a script like that, assuming
that the tests you listed above constitute the minimal suite of tests
that are required to prove that a GDB port is alive (or at least if
the set of the tests required for that doesn't change too much with
time).  If the set of tests changes too much, tracking them might not
be easy, given my free time (or should I say the lack thereof ;-)[1].

However, running the script once a month (on the then-latest snapshot,
I presume) is not something that I can afford, and I don't see anyone
else stepping forward to do that for me.

Since your proposal for deprecating counts minor releases, would it
be enough to request a run for every such release?

> If nobody does those things for a platform, then I want to obsolete the
> platform.

I think the degree to which such a logic is justified depends on the
platform.  For example, x86 platforms generally benefit from Mark
Kettenis's work and so are expected to bit-rot much slower than some
exotic platform that shares none of the code with others.

Isn't it better to start deprecating only if we know that some code
specific to a platform is broken by a certain change to GDB?  For
example, if some interface is deprecated and no one submitted
replacement code for a specific platform, then declare that platform
heading into obsolescence.

-----------------
Footnotes:

[1] Ironically, I suggested a couple of years ago (in a message I
cannot for the moment find in the archives) to add a script to the
gdb/config/djgpp directory that would run GDB against some subset of
the test suite, only without relying on `expect' and `dejagnu', and
compare the results against the expected ones.  However, both Andrew
and DJ thought the idea was not worth the effort, since simple textual
comparison, a-la "diff -ubBw", would bit-rot too quickly, due to
changes in GDB and local library developments.

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

> It should be relatively easy to produce a script like that, assuming
> that the tests you listed above constitute the minimal suite of tests
> that are required to prove that a GDB port is alive (or at least if
> the set of the tests required for that doesn't change too much with
> time).  If the set of tests changes too much, tracking them might not
> be easy, given my free time (or should I say the lack thereof ;-)[1].

As an aside, it is in theory possible to use dejagnu to test a remote 
go32 system.  I believe that the code is no longer used (it was 
developed to remote test cygwin) and presumably bitrotten.  So no way is 
any one going to be expected to run that, and I don't know that there is 
much return on investment.

Having said that, someone might find it useful as a tool that allows us 
to finally overhaul the *&!)($*&)(*@ coff code.

> However, running the script once a month (on the then-latest snapshot,
> I presume) is not something that I can afford, and I don't see anyone
> else stepping forward to do that for me.

I suspect michael might have been volunteering :-)

> Since your proposal for deprecating counts minor releases, would it
> be enough to request a run for every such release?

That's what actually happens :-)

Andrew

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Sun, 14 Dec 2003 01:23:35 -0500 (EST)
> From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
> 
> I mean to say: if there have been no test results submitted for a
> platform for gdb 5.2.1, gdb 5.3, or gdb 6.0, then I want to *start* the
> deprecation process for that platform.

There's something I'm probably missing here: who is responsible for
``submitting test results'' for a platform?

To make this more concrete, I don't think I (or anyone else) have ever
sent test results for the DJGPP (a.k.a. go32) target, for which I
alone am responsible.  Does that mean you will promote starting to
deprecate it VSN?

> I wanna do about 10 times as much QA as we are doing.

Thanks for all the hard work you are doing already.

Re: [commit] Deprecate remaining STREQ uses

[Jim Blandy]

[switched to gdb@]

Andrew Cagney <cagney@gnu.org> writes:
> > I suspect that what this boils down to is a difference in maintenance
> > philosophy: I would prefer to see old (deprecated) interfaces eliminated
> > as soon as possible even if it does involve touching possible candidates
> > for deletion, whereas you don't seem to mind having old interfaces
> > retained for longer periods of time.
> 
> To make this more concrete, perhaphs you could outline how this would
> have worked with the old vs new frame code.

Everyone posting so far has agreed that there are cases that are so
complex that deprecation is an appropriate strategy.  Having tried to
incrementally update a port from the old to the new frame interfaces,
but instead having given up and just rewritten it from scratch, I
would say that many aspects of the frame interface are clearly on the
"deprecation is appropriate" side of the line.

The issue at hand, STREQ, and the issue Kevin raised, complaints, are
cases that should have been on the other side of that line: just get
rid of the old uses immediately.  Maybe not in the same commit, but
certainly before taking up other projects.


But I think this principle does apply to the frame interfaces, just on
a different time scale:

After GDB 6.0 was released, you floated some ideas about renovating
the target vector.  While I like the direction these were going, I was
a little distressed to think that we were going to begin the process
of introducing a whole new class of deprecated target-related
interfaces before we had even finished removing uses of the deprecated
frame interfaces.  Certainly, we shouldn't wait for backwater *-tdep.c
files that nobody can test, but we still have deprecated frame
machinery in actively maintained targets like the MIPS and the
PowerPC.

I recognize that you and others have been working on these; I don't
mean to complain or be unappreciative.  But I think we should get
those taken care of before plunging into deprecating interfaces from
an entirely new section of GDB.

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

> [switched to gdb@]

Kevin Buettner writes:

>> > I suspect that what this boils down to is a difference in maintenance
>> > philosophy: I would prefer to see old (deprecated) interfaces eliminated
>> > as soon as possible even if it does involve touching possible candidates
>> > for deletion, whereas you don't seem to mind having old interfaces
>> > retained for longer periods of time.

Cagney asks:

>> To make this more concrete, perhaphs you could outline how this would
>> have worked with the old vs new frame code.

Jim Blandy replies:

> Everyone posting so far has agreed that there are cases that are so
> complex that deprecation is an appropriate strategy.  Having tried to
> incrementally update a port from the old to the new frame interfaces,
> but instead having given up and just rewritten it from scratch, I
> would say that many aspects of the frame interface are clearly on the
> "deprecation is appropriate" side of the line.
> 
> The issue at hand, STREQ, and the issue Kevin raised, complaints, are
> cases that should have been on the other side of that line: just get
> rid of the old uses immediately.  Maybe not in the same commit, but
> certainly before taking up other projects.

If you look at the thread you'll notice that the task was clearly 
non-trivial.  It required effort from both Kevin and I, it also 
identified and fixed bugs giving, in the end, an expected return on 
investment.  Did it have to be done immediatly and up front, I'd argue 
that the vote is still out.

Just remember that there is no simple straight line here, rather there 
is the squigly one drawn by those willing and able to do the real work 
that GDB requires.

> But I think this principle does apply to the frame interfaces, just on
> a different time scale:
> 
> After GDB 6.0 was released, you floated some ideas about renovating
> the target vector.  While I like the direction these were going, I was
> a little distressed to think that we were going to begin the process
> of introducing a whole new class of deprecated target-related
> interfaces before we had even finished removing uses of the deprecated
> frame interfaces.  Certainly, we shouldn't wait for backwater *-tdep.c
> files that nobody can test, but we still have deprecated frame
> machinery in actively maintained targets like the MIPS and the
> PowerPC.
> 
> I recognize that you and others have been working on these; I don't
> mean to complain or be unappreciative.  But I think we should get
> those taken care of before plunging into deprecating interfaces from
> an entirely new section of GDB.

Jim, Kevin, relax.

The new frame code was finished ~6 months ago (it took ~6 months 
although people have been talking about it for ~10 years).  Since then, 
  looking at the numbers, we find:

         alpha		done
         arm             done
         avr             done
         cris
         d10v            done
         frv             done
         h8300
         i386            done
         ia64            done
         m32r            done
         m68hc11         done
         m68k            done
         mcore
         mips
         mn10300         done
         ns32k
         pa
         powerpc
         s390            doneish
         sh              1/2
         sparc           doneish
         v850
         vax
         x86-64          done
         xstormy16

With IBM most recently stepping forward to contributing the necessary 
s390 code (paperwork pending TM).  Not bad, eh?

For the PowerPC, given the number of parties with a significant 
financial interest (IBM, Apple, Red Hat, Motorola, Novel (aka SuSE) ...) 
and the presence of this feature on at least two OS road maps, I'm sure 
someone will soon step forward and help Kevin with the task.

For the MIPS, while yes that is starting to show a few grey hairs, I've 
been quietly, efficiently and (well until now :) unassumingly, 
overhauling it (it stalled for a bit cos my main MIPS box died).

As for the other architectures, there's clearly no immediate concern. 
This code is relatively well isolated so can live a while longer. 
Further, the longer interested parties delay the work, the less real 
work they may need to do.  As you yourself observed, the occasional 
jumbo cleanup is often more efficient than constant incremental catchup. 
  We are of course going to need to find some sort of exit clause 
though, but I see MichaelC is already working towards that.


Having said all this, I can identify serious stagnation in areas where 
mechanisms have been deprecated.  Most notable is our target support 
(and there we've still a plithera of embedded targets).  Look at the 
count for the global deprecated_registers[] array which was declared bad 
how many years ago?
	mipsv4-nat.c:7
	rs6000-tdep.c:8
	core-sol2.c:10
	irix5-nat.c:10
	lynx-nat.c:12
	remote-vx68.c:13
	sun3-nat.c:14
	remote-vxsparc.c:15
	remote-vxmips.c:17
	sparc-nat.c:32
If we're to more rapidly advance GDB, adding/finishing key feaures such 
as "async" (needed by MI), fast thread support (needs target and infrun 
changes), and even multi-process debugging, we must become more 
agressive in this area.   That means cleaning up the relevant GNU/Linux 
targets, instigating changes target changes such as I proposed, and 
finally taking a good hard look at that long list at all those 
lingerking embedded targets.

Andrew

PS: For those that didn't know.  Intel ships a GDB CLI compatible 
debugger on GNU/Linux.  If anyone is looking for a reason to drive GDB's 
development harder, this is it.

Re: [commit] Deprecate remaining STREQ uses

[Michael Elizabeth Chastain]

Hi Eli,

> If you are proposing a change in the current strategy, this issue
> should be discussed (on gdb@, I guess).

Okay.

> For startesr, please define the ``long time'' after which it is okay, in
> your opinion, to deprecate a platform.

Three minor releases.

Supporting untested code costs resources because we can't upgrade the
code to use new interfaces.  If we drop untested code, it will be easier
to do work on the tested code.

If we want to drop a platform, and a user wants to keep it supported,
then they can volunteer to run the gdb test suite on it occasionally.

Michael C

Re: [commit] Deprecate remaining STREQ uses

[Eli Zaretskii]

> Date: Sat, 13 Dec 2003 10:23:56 -0500 (EST)
> From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
> 
> Supporting untested code costs resources because we can't upgrade the
> code to use new interfaces.

The fact that a certain platform doesn't get patches does not mean
that its code is not used.  So I'm not quite sure why you say
"untested code" here.

Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney]

> Hi Eli,
> 
> 
>> If you are proposing a change in the current strategy, this issue
>> should be discussed (on gdb@, I guess).
> 
> 
> Okay.
> 
> 
>> For startesr, please define the ``long time'' after which it is okay, in
>> your opinion, to deprecate a platform.
> 
> 
> Three minor releases.

That would be ~18 months which is significantly longer than the current 
process.  But then again, the current process starts several (like 10) 
years later than I suspect is being suggested here.

> Supporting untested code costs resources because we can't upgrade the
> code to use new interfaces.  If we drop untested code, it will be easier
> to do work on the tested code.

By testing, you mean run through the testsuite?  Yes.

We're caught between a rock and a hard place.  Do a blind rewrite of the 
old code (which is effectively guarenteed to be wrong but will let us 
fool ourselves into thinking its "fixed"); retain backward compatibility 
until it gets updated (which is guarenteed to suffer bitrot but 
hopefully less likely to immediatly break - presumably at the time of 
the change both the old and new ways were tested); remove the relevant 
code.  At present, by doing a combination of the latter two, we're able 
to extract an extra year or so out of the unmaintained code with not too 
much effort.

> If we want to drop a platform, and a user wants to keep it supported,
> then they can volunteer to run the gdb test suite on it occasionally.

We already have the occasional but steady updates/fixes that are made to 
architectures by architecture maintainers (and others).

Andrew