Re: -current build failure

On Sat, Jul 21, 2012 at 02:43:16PM +0300, Konstantin Belousov wrote:
> 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?
Oh, just for record. I forgot to note this first time, and almost missed it
now in response. The code in question _does not_ dereference NULL pointer.
It is artificial quirk in the GNU inline asm syntax that rvalue is needed
when I am passing memory _address_ to the asm.

> 
> 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 ?
>