Re: [PATCH] Fix step-over-signal-handler with merged Linux targets

[Daniel Jacobowitz <drow at false dot org>]

On Thu, Apr 06, 2006 at 02:33:40AM +0200, Ulrich Weigand wrote:
> Hello,
> 
> since the recent Linux target rework, the sigstep and sigrepeat
> test cases are failing for me.  The reason for this appears to be
> the following short-cut in linux_nat_wait:
> 
>   /* Don't report signals that GDB isn't interested in, such as
>      signals that are neither printed nor stopped upon.  Stopping all
>      threads can be a bit time-consuming so if we want decent
>      performance with heavily multi-threaded programs, especially when
>      they're using a high frequency timer, we'd better avoid it if we
>      can.  */
> 
> which didn't use to be active for single-threaded processes
> prior to the target rework.

Well, at least with your patch we have a net improvement over before
:-)  This will fix the matched bug for multithreaded programs.

Sorry for not getting to this earlier.  I must have missed the
sigrepeat.exp failure, probably because it's mixed in with a bunch
of signal tests whose results are disasterous on amd64.  Your
patch looks fine to me; could you commit it?

> 	* linux-nat.c (linux_nat_wait): Do not short-cut reporting
> 	of 'uninteresting' signals when single-stepping.

[I am slightly worried that another change will be needed for software
single step targets.  But signal handling on such targets is already in
bad shape and will need some handholding, so I'll defer that until I
have time to work on it.]

-- 
Daniel Jacobowitz
CodeSourcery