gdb 6.2 blockers

[Michael Elizabeth Chastain]

ac> - 1650 is an issue, but even there I'm wondering how much.  It's ticking 
ac> a horrible nasty race condition and may not be a real problem in the 
ac> field - do people really run 100 thread programs using linuxthreads.

1650, manythreads.exp, works every time with gdb 6.1.1.
So if there's a kernel race condition then gdb does not trigger it
and gdb HEAD does.  This is a user-visible regression.

ac> - architecture specific problems HP/UX, and much of e500, that can be 
ac> committed after the branch

1692 is not arch-specific.  The bug was introduced by a change in
bp_stop_status, and partially fixed by a change in bp_stop_status.
gdb recognizes its watchpoints now, but cannot backtrace after
hitting one.

The 32-vs-64-bit register change is definitely arch-specific.

All the changes are available at:

  http://www.shout.net/~mec/sunday/2004-07-02-hpux/difference/6.1-HEAD-0.html

I don't accept your conclusion that changes which manifest on hpux
must be in arch-specific code.  I won't know until I dig into each
of the 14 test scripts with regressed results.  It's up to me to do
that and file PR's.

Michael C