The following reply was made to PR amd64/163710; it has been noted by GNATS.
From: Peter Wemm <[email protected]> To: Russell Cattelan <[email protected]> Cc: [email protected] 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 <[email protected]> wrote: > 2012/3/16 Russell Cattelan <[email protected]>: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 3/16/12 3:51 PM, Peter Wemm wrote: >>> 2012/3/16 Russell Cattelan <[email protected]>: >>>> -----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 >>>>> <[email protected]> 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 - [email protected]; [email protected]; [email protected]; 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "[email protected]"
