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>
> >
>
prev parent 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