[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 9 Sep 2015 18:20:34 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Large stack alignment
On 2015-09-09 14:55, JimF wrote:
> On 9/9/2015 5:03 AM, magnum wrote:
>> On 2015-09-08 21:45, magnum wrote:
>>
>>> /*
>>> * I had to place this in a separate function to avoid having the
>>> unaligned
>>> * branch optimized away (even using -O0), since gcc is totally
>>> convinced it
>>> * simply can't be unaligned!
>>> */
>>> void out(char *pt)
>>> {
>>> if ((size_t)pt & 31)
>>> printf("%s unaligned!\n", pt);
>>> else
>>> puts(pt);
>>> }
>>
>> Come to think of it, this is troubling: It suggests that the macro
>> form of mem_align() might also be optimized away, doesn't it?!
>>
>> Also, I'm puzzled anything is optimized away at -O0. But it was -
>> there wasn't even any "%s unaligned!\n" string in the assembly output.
>>
> I believe this is going to be 2 different cases, but I honestly can not
> say for 100% sure. In the macro case, we have an lparam expression
> which sets an undefined variable. It must be run.
Yes, it looks like we are safe. gcc-4.8 reliably optimizes the test away
using the attached test program, but not the macro.
magnum
View attachment "test3.c" of type "text/plain" (1016 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
