Re: -current build failure

On Sat, Jul 21, 2012 at 01:35:26PM +0200, Dimitry Andric wrote:
> On 2012-07-21 01:16, Konstantin Belousov wrote:
> > On Fri, Jul 20, 2012 at 10:07:05PM +0100, David Chisnall wrote:
> >> On 20 Jul 2012, at 17:33, Konstantin Belousov wrote:
> >>
> >>> It is not related to dtrace at all, and indeed OFFSETOF_CURTHREAD is 0.
> >>> This is a bug in clang, we compile our kernel in freestanding environment.
> >>
> >> The copies of the C spec that I have do not differentiate between
> >> freestanding and hosted environments for the validity of dereferencing
> >> a pointer value of 0. Doing so is undefined in all cases and any
> >> standards-compliant compiler is quite at liberty to eat your dog in
> >> such situations - it is explicitly not guaranteed to read the memory at
> >> linear address 0 (this is undefined for at least two reasons that I can
> >> think of from the C spec, and probably more).
> > 
> > Ok, I stand corrected. But the standard does not say what you claim
> > either. It only specifies that NULL pointer is unequal to any pointer
> > to object or function (implicitely saying that you can create a C object
> > or function pointer to which is equal to NULL).
> > 
> > So, lets reformulate it other way: freestanding implementation in clang
> > has no use, at least for general purpose kernel. Especially ridiculous
> > is the fact that clang throws it hands for asm inline wanting to get
> > null address, on the machine with linearly addressable memory.
> 
> Oh come on, that's just hyperbole.  Everybody understands that directly
> dereferencing a NULL pointer is very unusual, in any environment.  It's
> perfectly sane to warn about it.  Is it such a big problem to simply
> insert a cast to tell the compiler you really want to do this, even if
> it is highly unusual?

The point of existence of the inline __pure2 __curthread() is to allow
a compiler to cache the result of the call. Basically, the curthread
dereference uses %gs basing, which typically adds a measurable penalty
on the frontend and sometimes on the execution as well.

Putting a volatile somewhere prevents the caching, right ? I am probably
fine with something along the lines of
#ifdef CLANG /* XXX what to put there */
#define VOLATILE volatile
#else
#define VOLATILE
#endif
and then use VOLATILE in the cast.

Could you recomment the best #if test ?

How to test the change ? Is CC=clang make buildkernel enough ?