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

[Peter Wemm]

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

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

 2012/3/16 Russell Cattelan <cattelan at thebarn.com>:
 > -----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 =A0 ${.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:
 > =A0 =A0 =A0 =A0ln -sf ${.CURDIR}/../../i386/include machine
 >
 > Are you suggesting that is incorrect and should be fixed?
 
 No, you're reading it wrong:
 "ln -sf ${.CURDIR}/../../i386/include machine"
 creates ${.OBJDIR}/machine"
 
 Your patch does a "rm -f   ${.CURDIR}/../../ficl/machine" which is in
 the source tree, not the obj tree, so it would never exist.  And if it
 does, then something is wrong with your build environment.
 
 --=20
 Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com; KI6FJV
 "All of this is for nothing if we don't go to the stars" - JMS/B5
 "If Java had true garbage collection, most programs would delete
 themselves upon execution." -- Robert Sewell