Date: Fri, 16 Mar 2012 23:00:16 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: <201203162300.q2GN0G1f078168@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 17:54:56 -0500
This is a multi-part message in MIME format.
--------------070204030709090807020609
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 3/16/12 5:35 PM, Peter Wemm 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 ${.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 ${.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.
>>>
>> This is pretty easy to reproduce. cd /sys/boot make
>
> You don't do that without a 'make obj' first.
So this is the only supported build model?
>
>> there will be a symlink in /sys/boot/ficl/machine that points to
>> i386/include.
>
> And this is user error. Don't do that.
if an inplace build is not supported then shouldn't it just
be flat out disabled?!!
What is wrong with making the build more robust to odd error are
not possible vs says "ohh ya don't do that"?
- -Russell
fwiw this is what happens if ficl/machine exists
(gdb) print sizeof(jmp_buf)
$1 = 48
(gdb) ptype jmp_buf
type = struct _jmp_buf {
int _jb[12];
} [1]
(gdb)
vs
(gdb) ptype jmp_buf
type = struct _jmp_buf {
long int _jb[12];
} [1]
(gdb) print sizeof(jmp_buf)
$1 = 96
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9jxMAACgkQNRmM+OaGhBiYTgCePFkTFRB78B9l/zgJ3xcV8JTe
5GgAn2yRdVK/vEWTSSRswCyU1E6j0jq5
=2JNI
-----END PGP SIGNATURE-----
--------------070204030709090807020609
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
--------------070204030709090807020609--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201203162300.q2GN0G1f078168>