Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Mar 2012 22:50:04 GMT
From:      Peter Wemm <peter@wemm.org>
To:        freebsd-amd64@FreeBSD.org
Subject:   Re: amd64/163710: setjump in userboot.so causes stack corruption
Message-ID:  <201203162250.q2GMo4CK069907@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR amd64/163710; it has been noted by GNATS.

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

 On Fri, Mar 16, 2012 at 3:35 PM, Peter Wemm <peter@wemm.org> wrote:
 > 2012/3/16 Russell Cattelan <cattelan@thebarn.com>:
 >> -----BEGIN PGP SIGNED MESSAGE-----
 >> Hash: SHA1
 >>
 >> On 3/16/12 3:51 PM, Peter Wemm wrote:
 >>> 2012/3/16 Russell Cattelan <cattelan@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@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: ln -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 =A0 ${.CURDIR}/../../ficl/machine" which is
 >>> in the source tree, not the obj tree, so it would never exist. =A0And
 >>> if it does, then something is wrong with your build environment.
 >>>
 >> This is pretty easy to reproduce.
 >> cd /sys/boot
 >> make
 >
 > You don't do that without a 'make obj' first.
 >
 >> there will be a symlink in /sys/boot/ficl/machine that points to
 >> i386/include.
 >
 > And this is user error. =A0Don't do that.
 
 More specifically..  You can't put code in the Makefiles that modifies
 the source tree explicitly.
 
 If sys/boot/userboot/ficl needs a different "#include <machine/*>"
 then sys/boot/userboot/ficl needs to create the machine link there and
 set the -I paths so that one has precedence.
 
 But reaching over and trying to modify another tool's build area is
 always wrong, aside from the obvious problem of it trying to modify
 the source tree.  If you're pulling the wrong include files into
 userboot/ficl, then that's because machine and -I aren't being set
 correctly in userboot/ficl/Makefile.
 
 --=20
 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@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



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