Date: Sat, 03 Jul 2010 10:27:54 +0800 From: David Xu <davidxu@freebsd.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: John Baldwin <john@baldwin.cx>, freebsd-arch@freebsd.org Subject: Re: Access to siginfo for the signal from debugger Message-ID: <4C2EA02A.70900@freebsd.org> In-Reply-To: <20100702124555.GR13238@deviant.kiev.zoral.com.ua> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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) --- Thanks,
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C2EA02A.70900>