Compiling this simple test case with
GNU C version 4.2.0 20060118 (experimental) (x86_64-unknown-linux-gnu)
extern void f2(char *s);
xorq __stack_chk_guard(%rip), %rax
addq $120, %rsp
Suggestions for improvement:
- It shouldn't use p2align 4,,5 for the __stack_chk_fail trampoline
because that wastes space in very infrequent code
- It should use jne to jump the function directly because it
should never return (when it is called the stack is compromised
and it would be a security hole)
Nope and Nope.
The alignment is because well -falign-jumps is default.
__stack_chk_fail is a noreturn function so we don't sib call it because it would be too hard for debugging.
Second jumping directly via an indirect branch is wrong as jumps only have a certain range.
You're wrong. On i386 and x86-64 call and conditional jumps have the same
That you're using the normal align-jumps for such uncommon code is a bug in my opinion and that is why I opened this request. It is a waste of space
for code that is known to be uncommon at compile time like this.
The debugging argument seems bogus in this case too. You'll see the
original function in the backtrace, but that is ok here.
Actually you will not see the correct backtrace, you will see the function which calls f and not f itself.
The alignment only saves instruction space it does nothing really
Yes that's the whole point of the bug. To save code space and precious
Use -Os for that.
-Os is only when there should be a trade off between size and performance.
But there isn't any performance consideration here because this code
is only executed on program abort.
(is there a button to reassign the bug to a non braindead bugmaster?)
The alignment does nothing, repeat nothing even if it is not executed that much, it does not change anything because it is last in the function. Try compiling more than this simple example and you will see that it always last for the emitted asm. Use -fno-align-jumps which is not default on x86.
And as I have mentioned before jumping directly to the other function is not useful at all (I already filed that bug and was shot down by RTH).
It seems to me that not aligning jumps for known infrequent jumps may be useful. Especially when you get so many of them as you do with ssp.
Again the alignment wastes precious icache which is enough reason to get
rid of it. If there are a lot of such functions it will also lead to
worse paging behaviour on big programs.
Can you explain again why it was shot down? Because of the missing frame
in the stack backtrace or something else?
noreturn vs sibcall:
I just checked and the problem is still there with
xorq %fs:40, %rax
addq $120, %rsp
unnecessary wasteful alignment for the call to
abort. The basic block should be marked cold.
Problem is still there in
gcc50 (GCC) 4.9.0 20130617 (experimental)
The stack protector edge should be cold and alignment disabled.