gdb 6.2 blockers

[Andrew Cagney]

Hello,

The first thing to do is look over what's already been fixed, and why we 
should push out a new release:

- signal trampolines ``work'' (ignoring kernel bugs :-)
- dwarf 2 cygwin support
- lots of new (or revised) native configurations
- this kvm thingie whats it (mark needs a news entry)
- the `start' command
- ppc64 is ``so much better''
- what else?

however, onto the issue.  Here's a list of what I know of that could 
potentially block 6.2:

1650: I suspect this is really a kernel race condition.
I remember that Jeff was pointing out that the bug this tickles is a 
race condition (hence isn't always reproducable).  The fix for NPTL 
involves kernel changes, I'm not sure about linuxthreads.

HP/UX: ``regressions''
This needs to be balanced against all the additional tests that do now 
pass.  Some bits are working much better than ever before, just not all :-)

vsyscall:
For those following BFD you'll see I'm having fun closing this :-)

PIE:
This stuff needs to be reviewed/merged.

inter-cu:
This stuff needs to be reviewed/merged.

e500:
Architecture problems.  Also dw_op_piece, xregset, ...

I think we can split this into three problems:

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

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

- new features - inter-cu, PIE, VSYSCALL, inter-cu, xregset? dw_op_piece
These should all go into the mainline.  In some cases, these have been 
missing for years.

Andrew