Date: Wed, 25 Jul 2012 21:10:43 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: John Marino <freebsdml@marino.st> Cc: freebsd-threads@freebsd.org Subject: Re: Signal trampoline frame changed location on FreeBSD 9 AMD64? Message-ID: <20120725181043.GP2676@deviant.kiev.zoral.com.ua> In-Reply-To: <50103539.5090200@marino.st> References: <50103539.5090200@marino.st>
next in thread | previous in thread | raw e-mail | index | archive | help
--EdHV1ukt9aOURWQF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 25, 2012 at 08:04:41PM +0200, John Marino wrote: > Hi guys, > I know this isn't a thread issue, but I'm hoping one of you either knows= =20 > the answer or can point me to someone that does. >=20 > After I patched lib/libthr/thread/thr_setschedparam.c, all the threading= =20 > issues with the GNAT testsuite running on FreeBSD 9.0 disappeared. On=20 > i386-FreeBSD, GNAT passes all tests perfectly. >=20 > This is not the case for x86_64-FreeBSD. GNAT fails all the stack-check= =20 > / dereference tests. It can no longer detect when it's at the end of=20 > the stack during the unwind process, because it can't find the signal=20 > trampoline. >=20 > For FreeBSD, it was easy. Use the kern.ps_strings sysctl and subtract X= =20 > from it's address (where X is 128 on i386 and 32 on AMD64). If the=20 > stack pointer is between the addr kern.ps_strings and addr=20 > kern.ps_strings - X then it's at the end of the stack. >=20 > For AMD64, according to GDB, it seems the signal trampoline frame is now= =20 > ahead of the ps_strings address rather than behind it. >=20 > Who can confirm this or conversely tell me how wrong I am? > By the way, if I'm right, it also breaks the base system's GDB=20 > end-of-stack detection as well. It uses the same algorithm. >=20 > I haven't tested this on FreeBSD 9.1 beta - just 9.0 release. =46rom quite some time, the signal trampoline was moved into the separate 'shared' page. This was done to allow to remove the executable permissions from the stack mapping. BTW, I do see that at least gdb 7.4.1 stock can detect our trampoline. In-tree gdb indeed have issue understanding signal stack frame. The way forward is to implement vdso and add dwarf annotation to the trampoline code. --EdHV1ukt9aOURWQF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAQNqMACgkQC3+MBN1Mb4gzeACbBjL47IdcOCdmquzxyLZHQa7s +JwAoOTaPMDZHz/Y+6GU5fXwTmF4VymJ =g6Ae -----END PGP SIGNATURE----- --EdHV1ukt9aOURWQF--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120725181043.GP2676>