Re: -current build failure

On Sat, Jul 21, 2012 at 12:59:07PM +0100, David Chisnall wrote:
> On 21 Jul 2012, at 00:16, Konstantin Belousov wrote:
> 
> > 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).
> 
> See 6.5.3.2, paragraph 4.  In particular:
> 
> > If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined.
> 
> and then (footnote 87 from the same page):
> 
> > Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer
> 
> 
> This clearly states that any dereference of the null pointer is explicitly invalid.  You can look up the correct paragraph for the other reason yourself (that any valid pointer must be the result of pointer arithmetic on a valid pointer).
> 
As I said in the followup, the C part of the code does not dereferences
NULL at all.

> > So, lets reformulate it other way: freestanding implementation in clang
> > has no use, at least for general purpose kernel.
> 
> The term 'freestanding' has a well-defined meaning in the C specification.  It does not mean 'the C memory model doesn't apply', it means that there is no underlying operating system providing facilities such as I/O.  Compiling for a freestanding target does not let you opt out of the C memory model.
> 
> > 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.
> 
> C is not a macro assembler, it is a well-defined (mostly) language with a complex memory model.  The relevant bit of code is:

Yes, implementation that interprets the freestanding this way is not
useful as a tool for implementing kernel.

> 
> >  (*(char *)OFFSETOF_CURTHREAD)
> 
> This is dereferencing the NULL pointer if OFFSETOF_CURTHREAD is 0.  If you want to pass the 0 into the assembly then passing it as something other than a memory operand would make sense.  Or, as the warning suggests, add a volatile qualification to indicate that the asm is not actually dereferencing this pointer.

I want the code to generate exact "movq %gs:0,%<any reg>" instruction,
without using volatile, and using C-level constant with the value of
offsetof(struct pcpu, pc_curthread), to be able to assert that
assumptions of the assembler fragment did not changed.

Your words about specifying immediate operand instead of memory reference
almost inevitably results in asm-level expression like $0, not 0. At least
I cannot write such asm constraint. You are welcome to provide the snippet.

> 
> However...
> 
> > 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.
> 
> Clang designates address space 256 for GS-relative addressing (and 257 for FS-relative addressing), so you don't need to use any assembly if all that you want to do is load something relative to one of these segments.  From the clang manual:
> 
> > Annotating a pointer with address space #256 causes it to be code generated relative to the X86 GS segment register, and address space #257 causes it to be relative to the X86 FS segment. Note that this is a very very low-level feature that should only be used if you know what you're doing (for example in an OS kernel).
> > 
> > Here is an example:
> > 
> 
> > #define GS_RELATIVE __attribute__((address_space(256)))
> > int foo(int GS_RELATIVE *P) {
> >   return *P;
> > }
> > 
> > Which compiles to (on X86-32):
> > 
> > _foo:
> > 	movl	4(%esp), %eax
> > 	movl	%gs:(%eax), %eax
> > 	ret
> 
> Using this instead of the inline asm allows the front end to perform
> numerous optimisations because it no longer has a bit of magic embedded
> in the middle of the code that the optimisers don't understand.

Great, how to express a fetch of the struct thread * from gs-based offset
0 using this machinery and both avoiding NULL pointer dereference warning
and avoiding an addition of volatile ?