Date: Fri, 2 Jul 2010 20:51:49 -0700 From: Garrett Cooper <gcooper@FreeBSD.org> To: David Xu <davidxu@freebsd.org> Cc: Kostik Belousov <kostikbel@gmail.com>, John Baldwin <john@baldwin.cx>, freebsd-arch@freebsd.org Subject: Re: Access to siginfo for the signal from debugger Message-ID: <AANLkTin-hOQSR93JxPuwFsBWl3W7llpnIR3G_ODk0eAC@mail.gmail.com> In-Reply-To: <4C2EA02A.70900@freebsd.org> References: <20100701134217.GM13238@deviant.kiev.zoral.com.ua> <201007011705.26173.john@baldwin.cx> <20100701212710.GP13238@deviant.kiev.zoral.com.ua> <4C2D4B65.8080708@freebsd.org> <20100702124555.GR13238@deviant.kiev.zoral.com.ua> <4C2EA02A.70900@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 2, 2010 at 7:27 PM, David Xu <davidxu@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 mo=
re
>>>>>> 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 betwee=
n
>>>>>> 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! =A0Does gdb "just work" with these changes or does it need patc=
hing
>>>>> 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 =A0a 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 c=
ont
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTin-hOQSR93JxPuwFsBWl3W7llpnIR3G_ODk0eAC>