public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Leif Lindholm" <leif.lindholm@linaro.org>
To: Laszlo Ersek <lersek@redhat.com>
Cc: "Philippe Mathieu-Daudé" <philmd@redhat.com>,
	devel@edk2.groups.io,
	"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
	"Bob Feng" <bob.c.feng@intel.com>,
	"Liming Gao" <liming.gao@intel.com>
Subject: Re: [edk2-devel] [PATCH 1/1] BaseTools: use stdint.h for GCC ProcessorBind.h typedefs
Date: Tue, 1 Oct 2019 10:58:38 +0100	[thread overview]
Message-ID: <20191001095838.GS25504@bivouac.eciton.net> (raw)
In-Reply-To: <b1ad9ca0-a740-92f7-d72a-17936bed5c81@redhat.com>

Thanks all - pushed as 5be5439a5a4e.

(And special thanks to Laszlo for the below.)

On Tue, Oct 01, 2019 at 12:01:31AM +0200, Laszlo Ersek wrote:
> On 09/27/19 12:06, Philippe Mathieu-Daudé wrote:
> > On 9/26/19 9:28 PM, Leif Lindholm wrote:
> >> The AArch64 definitions of UINT64/INT64 differ from the X64 ones.
> >> Since this is on the tool side, doing like X64 and picking the
> >> definitions from stdint.h feels like a better idea than hardcoding
> >> them. So copy the pattern from X64/ProcesorBind.h.
> > 
> > Typo: X64/ProcessorBind.h ('s' missing).
> > 
> >>
> >> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >> Cc: Bob Feng <bob.c.feng@intel.com>
> >> Cc: Liming Gao <liming.gao@intel.com>
> >> Cc: Laszlo Ersek <lersek@redhat.com>
> >> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
> >> ---
> >>
> >> This was triggered by one of the Risc-V patches which may need to end up
> >> being modified to the point where this issue goes away, but the current
> >> situation seems suboptimal. (Do you use %llx or %lx to print an Elf64_Addr
> >> on a 64-bit LP architecture?)
> > 
> > What is the answer? :)
> 
> For a hosted C99 program, you cast it to uint64_t, and print it with
> 
>   "%"PRIx64
> 
> (Note: "uint64_t" is an optional type, per C99.
> 
> """
> However, if an implementation provides integer types with widths of 8,
> 16, 32, or 64 bits, no padding bits, and (for the signed types) that
> have a two’s complement representation, it shall define the
> corresponding typedef names.
> """
> 
> The existence of Elf64_Addr suggests the implementation is like that,
> hence we can assume "uint64_t". Otherwise, we'd have to use
> "uint_least64_t" and "%"PRIxLEAST64.)
> 
> 
> When restricted to C89, you can only use "%lx" and "unsigned long", and
> you also have to rely on -- for example -- SUSv2 (from 1997 -- the last
> Single Unix Spec defined in terms of C89), for ensuring / selecting the
> XBS5_LP64_OFF64, or XBS5_LPBIG_OFFBIG compilation environments.
> 
> (SUSv2 defines uint64_t, so you could use that in itself, but SUSv2
> defines no matching format string macros, for printing uint64_t.)
> 
> How you print a 64-bit unsigned integer in Visual Studio, I can't say.
> It's not fully C99 conformant, it's likely also not SUSv2 conformant (in
> case we wanted to rely on C89 + SUSv2); so I have no idea. It's likely
> documented in MSDN or some place similar.
> 
> Thanks
> Laszlo
> 
> > 
> >>
> >>  BaseTools/Source/C/Include/AArch64/ProcessorBind.h | 26 ++++++++++----------
> >>  1 file changed, 13 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/BaseTools/Source/C/Include/AArch64/ProcessorBind.h b/BaseTools/Source/C/Include/AArch64/ProcessorBind.h
> >> index bfaf1e28e446..dfa725b2e363 100644
> >> --- a/BaseTools/Source/C/Include/AArch64/ProcessorBind.h
> >> +++ b/BaseTools/Source/C/Include/AArch64/ProcessorBind.h
> >> @@ -41,21 +41,21 @@
> >>    typedef signed char         INT8;
> >>  #else
> >>    //
> >> -  // Assume standard AARCH64 alignment.
> >> +  // Use ANSI C 2000 stdint.h integer width declarations
> >>    //
> >> -  typedef unsigned long long  UINT64;
> >> -  typedef long long           INT64;
> >> -  typedef unsigned int        UINT32;
> >> -  typedef int                 INT32;
> >> -  typedef unsigned short      UINT16;
> >> -  typedef unsigned short      CHAR16;
> >> -  typedef short               INT16;
> >> -  typedef unsigned char       BOOLEAN;
> >> -  typedef unsigned char       UINT8;
> >> -  typedef char                CHAR8;
> >> -  typedef signed char         INT8;
> >> +  #include <stdint.h>
> >> +  typedef uint8_t   BOOLEAN;
> >> +  typedef int8_t    INT8;
> >> +  typedef uint8_t   UINT8;
> >> +  typedef int16_t   INT16;
> >> +  typedef uint16_t  UINT16;
> >> +  typedef int32_t   INT32;
> >> +  typedef uint32_t  UINT32;
> >> +  typedef int64_t   INT64;
> >> +  typedef uint64_t  UINT64;
> >> +  typedef char      CHAR8;
> >> +  typedef uint16_t  CHAR16;
> >>  
> >> -  #define UINT8_MAX 0xff
> >>  #endif
> >>  
> >>  ///
> >>
> > 
> > Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
> > 
> 

      reply	other threads:[~2019-10-01  9:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-26 19:28 [PATCH 1/1] BaseTools: use stdint.h for GCC ProcessorBind.h typedefs Leif Lindholm
2019-09-27  0:16 ` Liming Gao
2019-09-27  0:30 ` Bob Feng
2019-09-27  7:52 ` Ard Biesheuvel
2019-09-27 10:06 ` [edk2-devel] " Philippe Mathieu-Daudé
2019-09-30 22:01   ` Laszlo Ersek
2019-10-01  9:58     ` Leif Lindholm [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191001095838.GS25504@bivouac.eciton.net \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox