gdb 6.2 blockers

[Manoj Iyer]

anyone got a chance to look at PR# 1704 ??

Thanks
Manjo

On Tue, 6 Jul 2004, Michael Elizabeth Chastain wrote:

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