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

[Luis Machado]

> One idea for less intrusive debugging would be to make it so
> the kernel doesn't notified of new threads/clones at all, IOW, not
> force parent/child clones to stop to report the child's existence to
> a ptracer (unless it wants to).  Having the kernel auto-copy debug
> resources in the new child is a requirement for that, and given
> ptrace options and other things are copied as well, I can't
> really call it broken outright.
>
> I'd suggest just mixing something like
>
>   Older kernels did not make new threads inherit their parent thread's
>   debug state, so we always clear the slot and replicate the debug state
>   ourselves, ensuring compatibility with all kernels.
>
> into the existing comment.
>

The comment looked thorough enough that i went with it.

> It does not:
>
> +# Run to `main' where we begin our tests.
> +if ![runto_main] then {
> +    fail "Failed to run to main"
> +}
> +

Really done now.
> Let's call "unsupported" or even FAIL then, so it can draw attention.
> We could also end up in that situation due to a bug somewhere in the
> test or gdb.  Something like 'fail "no hardware watchpoints"'.

Done.

>> +void empty_cycle (void)
>
> '\n' after first void.

Done.

>
>> +for { set i 1 } { $i <= $TRIGGERS} { incr i} {
>                              -------^    -----^
> Missing spaces.
>

Done.

>> +# Move the threads and hit the watchpoints
>> +# TRIGGERS times.
>
> Nit, that fits in a single line.

Done.

>
> Otherwise OK.

Thanks! I'll check it in later today.

Luis

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hw_watch.diff
Type: text/x-patch
Size: 12272 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20130425/ff7fe3e8/attachment.bin>