This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][alpha] Fix ____longjmp_chk


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~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]