linux-kernel - Re: [patch 2.6.19-rc6] Stop gcc 4.1.0 optimizing wait_hpet

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 7 Dec 2006 09:02:36 -0500
From:	Kyle Moffett <mrmacman_g4@....com>
To:	davids@...master.com
Cc:	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
	schwab@...e.de
Subject: Re: [patch 2.6.19-rc6] Stop gcc 4.1.0 optimizing wait_hpet_tick away

My apologies for the late response, I've had a lot on my schedule  
over the last week.

On Dec 02, 2006, at 23:29:28, David Schwartz wrote:
>>> It comes down to just what those guarantees GCC provides actually  
>>> are.
>
>> This is the first correct statement in your email.  In any case  
>> the documented GCC guarantees have always been much stronger than  
>> you have been trying to persuade us they should be.  I would argue  
>> that the C standard somewhat indirectly specifies those guarantees  
>> but I really don't have the heart for any more language-lawyering  
>> so I'm going to leave it at that.
>
> I have tried to find any documentation of the guarantees gcc  
> actually provides and have been unable to do so. Where are these  
> "documented GCC guarantees" documented?

Well, under "When is a Volatile Object Accessed" in the GCC manual  
(seems to be present for at least a few versions back):
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Volatiles.html#Volatiles

In that case it specifies that any evaluation of "*foo" in an rvalue  
context specifies a read (with a few exceptions for G++ where the C++  
language generally confuses things).  Specifically it mentions the  
statement "*src;" and discusses the statement as providing "a void  
context".  In other words, a statement such as "(void)(expr);" is  
redundant because the statement already implies void context and the  
extra cast-to-void is just extra text.  As such "(void)(*src);" on a  
"volatile int *src;" is documented to force a read of "*src".  Now,  
if you actually _use_ the result over just casting it to void and  
discarding it, then GCC can provide no _less_ guarantee with regards  
to the read-and-store than it provides to the read-and-discard.

For example:

/* This code is guaranteed to generate assembly to read the memory  
address into a register multiple times */
volatile int *foo = (expression);
*foo;
*foo;

/* This code is guaranteed to do the same */
volatile int *foo = (expression);
int x, y;
x = *foo;
y = *foo;

If the result is actually the conditional expression for a loop as in  
the problem code then GCC would plainly have no choice about  
optimizing, not only is the volatile variable read and returned, but  
the result is the conditional for continued execution of a block of  
code with unknown side effects.

Cheers,
Kyle Moffett

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/