[PATCH, ppc] Fix hw *points for embedded ppc in a threaded environment.

[Luis Machado]

Hi,

On 08/06/2012 11:33 AM, Luis Gustavo wrote:
> Hi,
>
> GDB has always assumed that hardware watchpoints and breakpoints should
> be replicated for every new thread in ppc. This worked fine for the old
> DABR-based mechanism since both server and embedded ppc's supported only
> a single hw watchpoint or breakpoint.
>
> With the somewhat recent booke kernel interface, more hw
> watchpoints/breakpoints are available to GDB.
>
> The logic of replicating the existing process' debug state to the new
> thread is still there though, but the new booke interface in the kernel
> already replicates that state. More precisely, the kernel gives the new
> thread the debug state of its parent thread.
>
> When GDB tries to replicate the debug state, it will actually cause the
> kernel to allocate a new hw *point entry, leading to inadequate
> consumption of hw debug resources.
>
> It's still unclear if the kernel is supposed to do this and i'm chasing
> answers with the ppc linux kernel folks
> (https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-August/100083.html).
> Nonetheless, the kernel is out and it has such behavior.
>
> This patch tries to address this problem by clearing any debug state
> prior to replicating *points to the new thread. If the kernel is doing
> something it's not supposed to, then this is a workaround for the broken
> kernels.

This is an updated patch that includes a generic testcase.

The fix is still the same, but the testcase exercises creation of 
hardware watchpoints and their replication to all existing threads.

Each thread should cause a watchpoint trigger a certain number of times, 
and that's what we expect in the testcase.

Without the fix, the affected ppc targets will throw an error after the 
third thread gets created.

Curiously, x86 misses a watchpoint trigger every once in a while. Since 
only a single trigger is allowed per thread at a given time, that is, we 
try our best not to cause multiple triggers at once,  this may be a 
different issue, not directly related to the testcase.

It would be nice if someone could try this testcase on different targets 
and confirm how it behaves, as well as validate the overall testcase format.

Regards,
Luis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-watch_threads.diff
Type: text/x-patch
Size: 10618 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20121227/807308b0/attachment.bin>