svn commit: r368329 - head/stand/kshim

[Warner Losh]

On Fri, Dec 4, 2020 at 9:06 AM Hans Petter Selasky <hps at selasky.org> wrote:

> On 12/4/20 4:59 PM, Alexander Richardson wrote:
> > On Fri, 4 Dec 2020 at 14:51, Hans Petter Selasky <hselasky at freebsd.org>
> wrote:
> >>
> >> Author: hselasky
> >> Date: Fri Dec  4 14:50:55 2020
> >> New Revision: 368329
> >> URL: https://svnweb.freebsd.org/changeset/base/368329
> >>
> >> Log:
> >>    Fix definition of int64_t and uint64_t when long is 64-bit. This
> gets the kernel
> >>    shim code in line with the rest of the kernel,
> sys/x86/include/_types.h.
> >>
> >>    MFC after:    1 week
> >>    Sponsored by: Mellanox Technologies // NVIDIA Networking
> >>
> >> Modified:
> >>    head/stand/kshim/bsd_kernel.h
> >>
> >> Modified: head/stand/kshim/bsd_kernel.h
> >>
> ==============================================================================
> >> --- head/stand/kshim/bsd_kernel.h       Fri Dec  4 14:09:12 2020
> (r368328)
> >> +++ head/stand/kshim/bsd_kernel.h       Fri Dec  4 14:50:55 2020
> (r368329)
> >> @@ -208,9 +208,17 @@ typedef unsigned int uint32_t;
> >>   #define        _INT32_T_DECLARED
> >>   typedef signed int int32_t;
> >>   #define        _UINT64_T_DECLARED
> >> +#ifndef __LP64__
> >>   typedef unsigned long long uint64_t;
> >> +#else
> >> +typedef unsigned long uint64_t;
> >> +#endif
> >>   #define        _INT16_T_DECLARED
> >> +#ifndef __LP64__
> >>   typedef signed long long int64_t;
> >> +#else
> >> +typedef signed long int64_t;
> >> +#endif
> >>
> >>   typedef uint16_t uid_t;
> >>   typedef uint16_t gid_t;
> >
> > Since we no longer support ancient compilers, could we simplify this
> > and just use
> > typedef __UINT64_TYPE__ uint64_t;
> > typedef __INT64_TYPE__ int64_t;
> > ?
> >
> > This will work across all architectures and ABIs, and appears to work
> > starting with GCC 4.5.3 and Clang 3.5:
> > https://godbolt.org/z/TWavfb
>
> Hi Alexander,
>
> I'm not sure how that definition will work together with existing code,
> mixing uint64_t, unsigned long, and unsigned long long. Will this cause
> more compiler warnings? This also will affect user-space and ports.
>

I think for the boot loader context, this suggestion will be completely
fine. Since this file is only used there, it should be identical to your
changes in that context.

Warner


> Maybe Konstantin, CC'ed, has some input on this?
>
> --HPS
>
>