This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb 6.2 blockers
- From: Manoj Iyer <manjo at austin dot ibm dot com>
- To: Michael Elizabeth Chastain <mec dot gnu at mindspring dot com>
- Cc: cagney at gnu dot org, gdb at sources dot redhat dot com
- Date: Tue, 6 Jul 2004 14:08:17 -0500 (CDT)
- Subject: Re: gdb 6.2 blockers
- References: <20040706182423.393F34B104@berman.michael-chastain.com>
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
>