[patch 0/4] Fix hw watchpoints

[patch 0/4] Fix hw watchpoints

[Jan Kratochvil]

Hi,

hw watchpoints currently have multiple issues for various corner cases, such
as false hits, hits shown by SIGTRAP with no watchpoint printed, crashing
forked processes, hanging fork etc.

Regression tested only as a whole patchset on:
x86_64-fedora11-linux-gnu
x86_64-fedora11-linux-gnu -m32
i686-fedora11-linux-gnu
ppc64-rhel52-linux-gnu
	with default ppc target, no regressions but some new FAILs which are
	not caused by the new code in these patches
ia64-rhel53-linux-gnu
	no regressions, new FAIL ("hbreak") which is not caused by the new
	code in these patches
s390x-rhel53-linux-gnu
	with default s390x target, no regressions, new FAILs, "reorder" is
	some pthreads/kernel bug or incompatibility, "watchpoints-hw" is not
	caused by the new code in these patches (did not analyze more)

Patches are incrementally dependent on each other.  Expecting to check-in all
of them together, their dependencies may not be strictly incremental.  The GDB
looks basically OK / tests OK on their incremental application (for testing).

While the non-stop mode was regression tested by the GDB testsuite I did not
consider much how the changes affect it.  I think some of the fixes are not
needed for non-stop.


Thanks,
Jan

Re: [patch 0/4] Fix hw watchpoints

[Doug Evans]

On Mon, Aug 17, 2009 at 12:45 PM, Jan
Kratochvil<jan.kratochvil@redhat.com> wrote:
> Hi,
>
> hw watchpoints currently have multiple issues for various corner cases, such
> as false hits, hits shown by SIGTRAP with no watchpoint printed, crashing
> forked processes, hanging fork etc.
>
> Regression tested only as a whole patchset on:
> x86_64-fedora11-linux-gnu
> x86_64-fedora11-linux-gnu -m32
> i686-fedora11-linux-gnu
> ppc64-rhel52-linux-gnu
>        with default ppc target, no regressions but some new FAILs which are
>        not caused by the new code in these patches
> ia64-rhel53-linux-gnu
>        no regressions, new FAIL ("hbreak") which is not caused by the new
>        code in these patches
> s390x-rhel53-linux-gnu
>        with default s390x target, no regressions, new FAILs, "reorder" is
>        some pthreads/kernel bug or incompatibility, "watchpoints-hw" is not
>        caused by the new code in these patches (did not analyze more)
>
> Patches are incrementally dependent on each other.  Expecting to check-in all
> of them together, their dependencies may not be strictly incremental.  The GDB
> looks basically OK / tests OK on their incremental application (for testing).
>
> While the non-stop mode was regression tested by the GDB testsuite I did not
> consider much how the changes affect it.  I think some of the fixes are not
> needed for non-stop.
>
>
> Thanks,
> Jan
>

Hi.  Have you looked at whether gdbserver has similar issues?

Re: [patch 0/4] Fix hw watchpoints

[Jan Kratochvil]

On Tue, 18 Aug 2009 18:24:00 +0200, Doug Evans wrote:
> Have you looked at whether gdbserver has similar issues?

No.

http://sourceware.org/ml/archer/2009-q2/msg00084.html
On Sun, 10 May 2009 17:42:48 +0200, Pedro Alves wrote:
# On Sunday 10 May 2009 15:55:49, Jan Kratochvil wrote:
# > May I ask why do you put effort both on linux-nat.c and gdbserver?  Isn't it
# > cheaper to unify the codebase and start (transparently) using gdbserver even
# > for local operations?
# 
# Probably, I think we're slowly going in that direction.  Making the
# debug interface control parts of gdbserver into a library and reuse
# it from gdb for native debugging (code sharing, that is) as been
# suggested many times.

Expecting currently I should copy the changes also to gdb/gdbserver/ .  Is it
OK to first get them approved for linux-nat.c & co. ?


Thanks,
Jan

Re: [patch 0/4] Fix hw watchpoints

[Doug Evans]

On Tue, Aug 18, 2009 at 9:37 AM, Jan
Kratochvil<jan.kratochvil@redhat.com> wrote:
> On Tue, 18 Aug 2009 18:24:00 +0200, Doug Evans wrote:
>> Have you looked at whether gdbserver has similar issues?
>
> No.
>
> http://sourceware.org/ml/archer/2009-q2/msg00084.html
> On Sun, 10 May 2009 17:42:48 +0200, Pedro Alves wrote:
> # On Sunday 10 May 2009 15:55:49, Jan Kratochvil wrote:
> # > May I ask why do you put effort both on linux-nat.c and gdbserver?  Isn't it
> # > cheaper to unify the codebase and start (transparently) using gdbserver even
> # > for local operations?
> #
> # Probably, I think we're slowly going in that direction.  Making the
> # debug interface control parts of gdbserver into a library and reuse
> # it from gdb for native debugging (code sharing, that is) as been
> # suggested many times.
>
> Expecting currently I should copy the changes also to gdb/gdbserver/ .  Is it
> OK to first get them approved for linux-nat.c & co. ?

Ah, righto.