Date: Fri, 16 Mar 2012 17:20:03 GMT From: Russell Cattelan <cattelan@thebarn.com> To: freebsd-amd64@FreeBSD.org Subject: Re: amd64/163710: setjump in userboot.so causes stack corruption Message-ID: <201203161720.q2GHK3IB067221@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: Russell Cattelan <cattelan@thebarn.com>
To: Peter Wemm <peter@wemm.org>
Cc: freebsd-gnats-submit@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@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@thebarn.com
tel;cell:612 805 3144
x-mozilla-html:FALSE
version:2.1
end:vcard
--------------020003020509030008080402--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203161720.q2GHK3IB067221>