From owner-freebsd-arch@FreeBSD.ORG Sat Jul 3 02:28:05 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from alona.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 4761B106566C; Sat, 3 Jul 2010 02:28:01 +0000 (UTC) (envelope-from davidxu@freebsd.org) Message-ID: <4C2EA02A.70900@freebsd.org> Date: Sat, 03 Jul 2010 10:27:54 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.21 (X11/20090522) MIME-Version: 1.0 To: Kostik Belousov 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> In-Reply-To: <20100702124555.GR13238@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: John Baldwin , freebsd-arch@freebsd.org Subject: Re: Access to siginfo for the signal from debugger X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 02:28:05 -0000 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 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,