Access to siginfo for the signal from debugger

[Garrett Cooper]

On Fri, Jul 2, 2010 at 7:27 PM, David Xu <davidxu at freebsd.org> 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)

    strerror(EOK) is ok, if signal doesn't return SIG_ERR and
sigaction doesn't return -1.
-Garrett