Access to siginfo for the signal from debugger

[Kostik Belousov]

On Sat, Jul 03, 2010 at 10:27:54AM +0800, David Xu wrote:
> Kostik Belousov wrote:
> >On Fri, Jul 02, 2010 at 10:13:57AM +0800, David Xu wrote:
> >  
> >>Kostik Belousov wrote:
> >>    
> >>>On Thu, Jul 01, 2010 at 05:05:26PM -0400, John Baldwin wrote:
> >>>      
> >>>>On Thursday 01 July 2010 09:42:17 am Kostik Belousov wrote:
> >>>>        
> >>>>>Hi,
> >>>>>below is the patch that provides the debugger with access to siginfo
> >>>>>of the signal that stopped the debuggee. This allows to see a lot more
> >>>>>details for the cause of the process stop. E.g. you can see a fault
> >>>>>address if process get SIGSEGV or SIGBUS, you can distinguish between
> >>>>>breakpoint-generated SIGTRAP and non-breakpoint, whether the signal
> >>>>>was send due to external event etc.
> >>>>>
> >>>>>The change to struct ptrace_lwpinfo is backward-compatible in the sense
> >>>>>that programs that were compiled with old definition for the struct 
> >>>>>will
> >>>>>work on new kernels.
> >>>>>          
> >>>>Nice!  Does gdb "just work" with these changes or does it need patching 
> >>>>as well?
> >>>>        
> >>>It should "just work", and my testing seems to confirm this. gdb uses
> >>>PT_LWPINFO to enumerate the thread ids, and I checked it on mt process.
> >>>
> >>>As I said, the change is ABI backward-compatible, i.e. you do not need
> >>>even to recompile the old program for new kernel.
> >>>
> >>>Sure, gdb cannot show additional available information without
> >>>modifications.
> >>>      
> >>Yes, you can add new fields to ptrace_lwpinfo without any problem.
> >>To print new fields, you should change the function
> >>fbsd_thread_signal_cmd in file
> >>src/gnu/usr.bin/gdb/libgdb/fbsd-threads.c
> >>after change, you just type 'thread signal' command in gdb to
> >>show thread's signal info. The command is freebsd specific,
> >>others may or may not have it.
> >>    
> >
> >I did what you suggested. The drawback there is that "thread signal"
> >only works for the threaded processes.
> >  
> 
> I have tested it, it works fine. yes, it only works for threaded target.
> The only problem is strerror(0) returns 'Unknown error', this is  a bit
> strange.
> 
> ---
> Program received signal ?, Unknown signal.
> [Switching to Thread 800c07700 (LWP 100165)]
> 0x00000008008bd1ac in sigwaitinfo () from /lib/libc.so.7
> (gdb) thread signal
> signal mask:
> hup int quit ill trap abrt emt fpe bus segv sys pipe alrm term urg tstp 
> cont chl
> d ttin ttou io xcpu xfsz vtalrm prof winch info usr1 usr2 <snip>
> signal pending:
> 
> si_signo 33
> si_errno 0 (Unknown error: 0)
> si_code TIMER si_pid 0 si_uid 0 si_status 0 si_addr 0x0
> (gdb)
> ---
Thank you. The strerror(0) behaviour seems to be introduced in r108044:
    strerror()'s semantics have changed slightly such that an argument of
    0 is now considered invalid and errno is set to EINVAL.
We indeed do not have defined symbol for errno value of 0, I might
just special-case the 0 in si_errno for aestetic purpose.

Another small nit in the patch is that I do not fetch siginfo for
the signal delivered to system-scoped kse thread, but I think that
this is acceptable.

I am going to commit this, with the modification mentioned above.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20100703/4f85210c/attachment.pgp