address_space and noderef on non-pointer types

address_space and noderef on non-pointer types

[David Malcolm]

Is it valid to apply the sparse attributes 'noderef' or 'address_space'
to non-pointers, and if so, what does this mean?

I see examples of using them on non-pointers in sparse's own test
suite.

For example, in:
https://git.kernel.org/pub/scm/devel/sparse/sparse.git/tree/validation/type-attribute-as.c
"struct s" is annotated with
  __attribute__((address_space(__as)))

Similarly, there's
https://git.kernel.org/pub/scm/devel/sparse/sparse.git/tree/validation/noderef.c#n18
where sparse accepts:
  struct x __A x;
e.g.:
  struct x __attribute__((noderef)) x;

The docs for noderef: 
https://git.kernel.org/pub/scm/devel/sparse/sparse.git/tree/Documentation/annotations.rst#n54
say:
"This attribute is to be used on a r-value to specify it cannot be
dereferenced. A pointer so annotated is in all other aspects exactly
like a pointer  but trying to actually access anything through it will
cause a warning."
What is the intended meaning of "noderef" for a non-pointer?

Similarly, the docs for "address_space" say:
"This attribute is to be used on pointers to specify that its target is
in address space *name* (an identifier or a constant integer)."

but don't specify what it means to use in on a non-pointer.

Sorry if this is a silly question.

The background here is that I'm a GCC developer and have been
experimenting with implementing some sparse attributes and warnings
"natively" in GCC; see e.g. the RFE in GCC bugzilla for implementing
address_space, noderef and force here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 ; I'm trying to get
my patched GCC to handle Sparse's own test suite and hence running into
this issue.

Thanks
Dave

Re: address_space and noderef on non-pointer types

[Linus Torvalds]

On Thu, Oct 13, 2022 at 12:37 PM David Malcolm <dmalcolm@redhat.com> wrote:
>
> Is it valid to apply the sparse attributes 'noderef' or 'address_space'
> to non-pointers, and if so, what does this mean?

It means that the thing itself is in said address space and cannot be
accessed directly.

IOW, if you have something like this (I'll just use "__percpu" as an
example from the kernel):

    # define __percpu __attribute__((noderef, address_space(__percpu)))

then

    int __percpu x;

means that you cannot access the value of 'x' directly, and that x
itself is in the "__percpu" address space.

Trying to use the value of 'x', eg

       printf("%d\n", x);

should cause a warning, along the lines of

     warning: dereference of noderef expression

and taking the address of 'x' should result in a pointer that is of type

   int __percpu *

which is entirely consistent (and then you'd have an inline function
or macro that then does the right magic to dereference a pointer in
that __percpu address space, in the kernel it would be
"this_cpu_read()" and friends).

> What is the intended meaning of "noderef" for a non-pointer?

Note that the pointer use is the common (and historical) use in the
kernel, but "noderef" really is not so much about the pointer, it's
about what the pointer points to.

IOW, notice that when you have a pointer to a __percpu variable, you
don't mark the *pointer* as being __percpu. It's not "int *ptr
__percpu", it's "int __percpu *ptr".

(Ok, "int *ptr __percpu" does conceptually exist, but it means that
the pointer itself is just an "int *", but it is in __percpu space, so
it's not about how the pointer cannot be dereferenced - you cannot
actually access the pointer value itself!).

So the type system is entirely consistent.

The documentation (and the naming) may be a bit pointer-centric, and
that in turn comes from the historical use of this originally only
being used for things like user pointers, but also from the fact that
internally in sparse, accessing a variable is actually the same as
dereferencing the symbol.

           Linus