On 04/09/2013 02:41 PM, Robert Dewar wrote:
On 4/9/2013 5:39 AM, Florian Weimer wrote:
On 04/09/2013 01:47 AM, Robert Dewar wrote:
Well the back end has all the information to figure this out I think!
But anyway, for Ada, the current situation is just fine, and has
the advantage that the -gnatG expanded code listing clearly shows in
Ada source form, what is going on.
Isn't this a bit optimistic, considering that run-time overflow checking
currently does not use existing hardware support?
Not clear what you mean here, we don't rely on the back end for run-time
overflow checking. What is over-optimistic here?
BTW, existing hardware support can be a dubious thing, you have
to be careful to evaluate costs, for instance you don't want to
use INTO on modern x86 targets!
It's not aobut INTO, just access to the overflow flag.
A simple function which adds its two Integer arguments compiles to this
machine code (with -gnato -O2):
.cfi_startproc
movslq %esi, %rax
movslq %edi, %rdx
addq %rax, %rdx
movl $2147483648, %eax
addq %rax, %rdx
movl $4294967295, %eax
cmpq %rax, %rdx
ja .L5
leal (%rsi,%rdi), %eax
ret
.L5:
pushq %rax
.cfi_def_cfa_offset 16
movl $3, %esi
movl $.LC0, %edi
xorl %eax, %eax
call __gnat_rcheck_10
.cfi_endproc
While it could be like this:
.cfi_startproc
movl %edi, %eax
addl %esi, %eax
jo .L5
ret
.L5:
pushq %rax
.cfi_def_cfa_offset 16
movl $3, %esi
movl $.LC0, %edi
xorl %eax, %eax
call __gnat_rcheck_10
.cfi_endproc
Admittedly, I haven't benchmarked it, but at least from the code size
aspect, it's a significant improvement.
--
Florian Weimer / Red Hat Product Security Team
