This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][alpha] Fix ____longjmp_chk
- From: Richard Henderson <rth at twiddle dot net>
- To: Aurelien Jarno <aurelien at aurel32 dot net>
- Cc: libc-ports at sourceware dot org, libc-alpha at sourceware dot org
- Date: Tue, 22 Mar 2011 12:10:58 -0700
- Subject: Re: [PATCH][alpha] Fix ____longjmp_chk
- References: <20110319122929.GA12598@volta.aurel32.net>
On 03/19/2011 05:29 AM, Aurelien Jarno wrote:
> ____longjmp_chk is broken on alpha due to a wrong register used for a
> comparison. The patch below fixes that and with it the following
> testsuite errors:
> - tst-longjmp_chk.out, Error 1
> - tst-chk2.out, Error 127
> - tst-chk3.out, Error 127
> - tst-chk5.out, Error 127
> - tst-chk6.out, Error 127
> - tst-lfschk2.out, Error 127
> - tst-lfschk3.out, Error 127
> - tst-lfschk5.out, Error 127
> - tst-lfschk6.out, Error 127
>
> 2011-03-20 Aurelien Jarno <aurelien@aurel32.net>
>
> * sysdeps/unix/sysv/linux/alpha/____longjmp_chk.S(____longjmp_chk):
> Fix wrong register in stack pointer comparison.
>
> diff --git a/sysdeps/unix/sysv/linux/alpha/____longjmp_chk.S b/sysdeps/unix/sysv/linux/alpha/____longjmp_chk.S
> index 5194ed8..e0e7106 100644
> --- a/sysdeps/unix/sysv/linux/alpha/____longjmp_chk.S
> +++ b/sysdeps/unix/sysv/linux/alpha/____longjmp_chk.S
> @@ -58,7 +58,7 @@ ____longjmp_chk:
> PTR_DEMANGLE2(s3, t1)
> PTR_DEMANGLE2(fp, t1)
> #endif
> - cmpule t0, sp, t1
> + cmpule s3, sp, t1
> bne t1, .Lfail
While it's true that we're using the wrong register here, this whole test
seems highly questionable. The main problem with this test is that Alpha
does *not* place the main stack at the top of memory; by default it's
actually below the main executable code segment, growing down from 6G.
Any malloced or bss space that might be present for sigaltstack will be
above the main stack, and thus not go to .Lfail anyway.
Frankly, all the ports appear to have a similar problem, if one considers
the stack bounds of a thread other than the main. Secondary threads will
have stack bounds interspersed with other malloc memory. Both the low
and high bounds need to be checked.
And someone correct me if I'm wrong, but it appears as if the x86 versions
have the entirely wrong test:
cmpq %r8, %rsp
jbe .Lok
if (new <= low_bound) goto ok;
Er... really?
r~