Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 3 Jul 2010 14:31:13 +0300
From:      Kostik Belousov <kostikbel@gmail.com>
To:        David Xu <davidxu@freebsd.org>
Cc:        John Baldwin <john@baldwin.cx>, freebsd-arch@freebsd.org
Subject:   Re: Access to siginfo for the signal from debugger
Message-ID:  <20100703113113.GF13238@deviant.kiev.zoral.com.ua>
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

--i0lx7FdJFH1KG+55
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
> > =20
> >>Kostik Belousov wrote:
> >>   =20
> >>>On Thu, Jul 01, 2010 at 05:05:26PM -0400, John Baldwin wrote:
> >>>     =20
> >>>>On Thursday 01 July 2010 09:42:17 am Kostik Belousov wrote:
> >>>>       =20
> >>>>>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 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 se=
nse
> >>>>>that programs that were compiled with old definition for the struct=
=20
> >>>>>will
> >>>>>work on new kernels.
> >>>>>         =20
> >>>>Nice!  Does gdb "just work" with these changes or does it need patchi=
ng=20
> >>>>as well?
> >>>>       =20
> >>>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.
> >>>     =20
> >>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.
> >>   =20
> >
> >I did what you suggested. The drawback there is that "thread signal"
> >only works for the threaded processes.
> > =20
>=20
> 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.
>=20
> ---
> 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=
=20
> cont chl
> d ttin ttou io xcpu xfsz vtalrm prof winch info usr1 usr2 <snip>
> signal pending:
>=20
> 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.

--i0lx7FdJFH1KG+55
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (FreeBSD)

iEYEARECAAYFAkwvH4EACgkQC3+MBN1Mb4gn3gCg5sytrvcWL+MQy3r+UDKASk3b
qr8AoLp5A8HGbd1lpHVRCnBZYa8vbemp
=hbHS
-----END PGP SIGNATURE-----

--i0lx7FdJFH1KG+55--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100703113113.GF13238>