On Friday 09 September 2011 16:11:09, Pedro Alves wrote:
> On Friday 09 September 2011 16:03:43, Abhijit Halder wrote:
> > Hi,
> > 
> > I was browsing through the internet and found that a bug (Bug 7221) is
> > already filed for this feature. I am interested to know whether this
> > is already implemented or somebody is working on this feature. If not,
> > I am planning to start with this.
> 
> I've got a 90% done patch for that.  Let me look for it...

Here is is.  3 patches actually.  The first two lay the path to
be able to pass down the current event's waitstatus down through 
bpstat_stop_status to the catchpoint's breakpoint_hit callbacks.
The third actually implements the feature.  It looks like:

(top-gdb) catch signal 5
Catchpoint 6 (signal 5)
(top-gdb) commands 
Type commands for breakpoint(s) 6, one per line.
End with a line saying just "end".
>echo caught!\n
>end
(top-gdb) n

Catchpoint 6 (signal 5), 0x0000000000451431 in main (argc=1, argv=0x7fffffffe068) at ../../src/gdb/gdb.c:30
30        memset (&args, 0, sizeof args);
caught!
(top-gdb) 

You'll notice the catch signal code looks a lot like the catch
syscalls code.  That's because I started out with mostly
copy&pasting the syscalls code.  There's certainly cruft
in there.  :-)

This is missing being able to specify signals by name, and,
there's no integration with "handle" presently.  E.g, if
the user says "handle FOO pass nostop noprint", then the
linux target backend will report stops for FOO signal
to the core.  We'll need to make infrun.c:signal_pass
(for target_pass_signals) consider FOO due to "catch signal FOO"
somehow.  It also lacks documentation, of course.  :-)

(I wrote this as a proof of concept for some special
catchpoints for an unsubmitted target support, and it
was catchpoints like these that mostly drove the recent
breakpoint changes that made catchpoints implementable
outside of breakpoint.c.)

-- 
Pedro Alves