Date: Sat, 11 Feb 2012 17:49:07 -0600 From: Russell Cattelan <cattelan@thebarn.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-amd64@freebsd.org Subject: Re: amd64/163710: setjump in userboot.so causes stack corruption Message-ID: <4F36FE73.3000101@thebarn.com> In-Reply-To: <20120211074811.GR3283@deviant.kiev.zoral.com.ua> References: <201202110430.q1B4UGPe088047@freefall.freebsd.org> <20120211074811.GR3283@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------070708000102000007000601 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/11/12 1:48 AM, Konstantin Belousov wrote: > On Sat, Feb 11, 2012 at 04:30:16AM +0000, Russell Cattelan wrote: >> The following reply was made to PR amd64/163710; it has been >> noted by GNATS. >> >> From: Russell Cattelan <cattelan@thebarn.com> To: >> bug-followup@FreeBSD.org, cattelan@thebarn.com Cc: Subject: Re: >> amd64/163710: setjump in userboot.so causes stack corruption >> Date: Fri, 10 Feb 2012 22:04:52 -0600 >> >> So here is a suggestion. >> >> So the default build does do the right thing. >> >> The problem is when doing userboot development the symlink from >> the loader build ends up including the wrong files. >> >> the userboot build of fill does not need a sym link so make sure >> the link does not exist when doing the build. >> >> This make sure the right header files are used for userboot >> builds=20 > I suspect this will break cross-builds. > > If the issue is in wrong machine/ symlink being installed, should > this be fixed instead ? The sym link is correct machine -> i386 for the loader since the loader is always built 32bit. But the symlink is wrong when building userboot, so the standard build builds userboot first when the sym link does not exist. The problems shows up when doing an incremental build of userboot more specifically ficl since now the sym link is pointing to the wrong spot. Removing the sym link simply makes sure it does not exist when doing the build. If ficl is being rebuild for the loader then the Makefile for ficl will simply put the sym link back and everything is happy. Again this is and issue for incremental builds and not the standard from scratch build. - -Russell -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk82/nMACgkQNRmM+OaGhBgOIgCfVJgEB+Lg0KUI4Gs2bqFQGeAR cRYAmgM1qlC2hj3xujvJ6TkT/IpFmxO6 =F7yF -----END PGP SIGNATURE----- --------------070708000102000007000601--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F36FE73.3000101>