Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 11 Jan 2019, Stewart Hildebrand wrote:
> On Friday, January 11, 2019 3:36 PM, Julien Grall wrote:
> > On Fri, 11 Jan 2019, 12:53 Stewart Hildebrand wrote:
> > >
> > > Why don't we change the type of _start so it's not a pointer type?
> >
> > Can you suggest a type that would be suitable?
> >
> > Cheers,
> 
> Yes. My opinion is that the "sufficient-width integer type" should be a
> "uintptr_t" or "intptr_t", since those types by definition are *integer* types
> wide enough to hold a value converted from a void pointer. While "unsigned
> long" seems to work for Linux, the definition of that type doesn't provide the
> same guarantee. Since uintptr_t is an *integer* type by definition (and not a
> pointer type), my interpretation of the C standard is that
> subtraction/comparison of uintptr_t types won't be subject to the potential
> "pointer to object" issues in question.
> 
> If I had to choose between "uintptr_t" or "intptr_t" I guess I would choose
> "uintptr_t" since that type is already used in various places in the Xen
> codebase. And the Linux workaround is also using an unsigned integer type.

On changing type of _start & friends: we cannot declare _start as
uintptr_t, the linker won't be able to set the value. It needs to be an
array type. At that point, it is basically a pointer, it doesn't matter
if it is a char[] or uintptr_t[]. It won't help.

But, instead of converting _start to unsigned long via SYMBOL_HIDE, we
could convert it to uintptr_t instead, it would be a trivial change on
top of the existing unsigned long series. Not sure if it is beneficial.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel