amd64/163710: setjump in userboot.so causes stack corruption

[Russell Cattelan]

The following reply was made to PR amd64/163710; it has been noted by GNATS.

From: Russell Cattelan <cattelan at thebarn.com>
To: Peter Wemm <peter at wemm.org>
Cc: freebsd-gnats-submit at freebsd.org
Subject: Re: amd64/163710: setjump in userboot.so causes stack corruption
Date: Fri, 16 Mar 2012 12:12:27 -0500

 This is a multi-part message in MIME format.
 --------------020003020509030008080402
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: 7bit
 
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
 On 3/16/12 11:56 AM, Peter Wemm wrote:
 > On Thu, Mar 15, 2012 at 2:40 PM, Russell Cattelan
 > <cattelan at thebarn.com> wrote:
 >> The following reply was made to PR amd64/163710; it has been
 >> noted by GNATS.
 > [..]
 >> Does the last patch seem acceptable?
 >> 
 >> Can we close this issue out?
 > 
 > Sadly not,
 > 
 > +no-machine: + rm -f   ${.CURDIR}/../../ficl/machine
 > 
 > .. this is definitely bogus no matter what. This attempts to
 > modify the source tree which may be read only, and should never
 > even have a "machine->..." symlink in it to remove in the first
 > place.
 The sym link is created by the build of ficl for the loader.
 See: boot/ficl/Makefile
 machine:
 	ln -sf ${.CURDIR}/../../i386/include machine
 
 Are you suggesting that is incorrect and should be fixed?
 
 > 
 > I see sys/boot/userboot/ficl/Makefile has commented out the code
 > that sets up the ./machine links in its ${.OBJDIR} and there's -I
 > paths all over the place so my guess is that it's picking up some
 > of the i386 machine links rather than setting up its own.  You
 > probably need to look at the userboot/ficl/Makefile code and make
 > sure its setting up the correct links rather than accidently using
 > one belonging to something else.
 Well let me explain this again.
 If the build is done from scratch things work because
 boot/userboot/ficl is built before boot/ficl.
 If an incremental build is done (e.g. when doing devel on the userboot
 lib) boot/userboot/ficl will end up picking up i386 header files due
 to the symlink that was created by boot/ficl/Makefile
 
 I'll will grant you this bug isn't hit by a normal full build due
 to way the build it ordered.
 The problem is incremental builds, that IMHO shouldn't be creating
 a bad userboot.so lib.
 
 
 > 
 > Or your source tree is contaminated somehow with a machine-> link 
 > somewhere that it isn't supposed to be.
 The problems exists in a stock freebsd src tree this is not a problem
 created by anything I'm working on.
 
 - -Russell
 
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (Darwin)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
 iEYEARECAAYFAk9jdHsACgkQNRmM+OaGhBiKTQCdHdqVxq1KMr0sPEE2epxOZrHx
 uTgAn0cDP90aJvsK6aFBZYtuAFpPWzEd
 =oYfT
 -----END PGP SIGNATURE-----
 
 --------------020003020509030008080402
 Content-Type: text/x-vcard; charset=utf-8;
  name="cattelan.vcf"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="cattelan.vcf"
 
 begin:vcard
 fn:Russell Cattelan
 n:Cattelan;Russell
 email;internet:cattelan at thebarn.com
 tel;cell:612 805 3144
 x-mozilla-html:FALSE
 version:2.1
 end:vcard
 
 
 --------------020003020509030008080402--