[lttng-dev] current_thread_info() not respecting program order with gcc 4.8.x

[Bhaskar Janakiraman]

On Thu, Nov 21, 2013 at 2:32 PM, Linus Torvalds <
torvalds at linux-foundation.org> wrote:

> On Thu, Nov 21, 2013 at 8:02 AM, Alexander Holler <holler at ahsoftware.de>
> wrote:
> >
> > Luis Lozano just noted (see https://lkml.org/lkml/2013/11/20/625) that
> > current_thread_info() has the prototype
> >
> > static inline struct thread_info *current_thread_info(void)
> > __attribute_const__;
> >
> > on arm (and arm64 and unicore32, something the paste from Mathieu missed
> so
> > most people here might have missed that detail too). It's a very good
> > finding from Luis.
>

Can someone provide a test case? We are unable to reproduce the problem in
ChromeOS land.


>
> No, because it is immaterial.
>
> We *want* gcc to optimize away multiple accesses to "sp". Because it
> doesn't *matter* whether "sp" changes or not, the *result* is always
> the same. That's what the "const" means.
>
> The "& ~(THREAD_SIZE - 1)" part will remove all the bits that can
> change. Really. So the result *is* constant (within one thread).
> Marking it constant and telling gcc that it can combine these things
> is correct.
>

Its unfortunate that the attribute '__const__ ' is very misleading - the
semantic used by gcc is that this is an aliasing attribute that implies
that the function does not depend in any way on global state. Meaning, if
called with the same parameters, it expected to return the same value. It
should have been called 'pure', but gcc has a different 'pure' attribute
that imples something different :-(

That said, gcc should be smart enough to figure out that this function is
 not doing anything complicated. Again, a test case would be much
appreciated.

Bhaskar



> Guys, read my email again.
>
> The bug is not that gcc can re-order or combine the accesses to "sp".
> WE WANT THAT TO HAPPEN.
>
> The bug is *outside* that "current_thread_info()" macro/inline
> function. It's the *dereference* of the pointer that gcc re-orders.
> AND THAT IS WRONG.
>
> Gcc seems to mess up the alias analysis, and decide that the
> deferences cannot alias. Which is wrong. They clearly *can* alias,
> exactly because the value of "sp & ~(THREAD_SIZE - 1)" ends up having
> the same value all the time.
>
>






                 Linus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20131121/7c74e8e2/attachment-0001.html>