Patchwork [3/7] Add stdint.h wrapper for VxWorks.

login
register
mail settings
Submitter rbmj
Date June 6, 2012, 4:36 p.m.
Message ID <4FCF8724.9020600@verizon.net>
Download mbox | patch
Permalink /patch/163395/
State New
Headers show

Comments

rbmj - June 6, 2012, 4:36 p.m.
The stdint.h doesn't have all the typedefs needed for standards
compliance, so add a hack that adds all of the needed typedefs
to be fully compliant to the standard.  Fixes broken libstdc++.

Changes:

     * fixincludes/inclhack.def: Added AAB_vxworks_stdint fix
---
  fixincludes/inclhack.def |   44 
++++++++++++++++++++++++++++++++++++++++++++
  1 files changed, 44 insertions(+), 0 deletions(-)
Joseph S. Myers - June 12, 2012, 3:47 p.m.
On Wed, 6 Jun 2012, rbmj wrote:

> The stdint.h doesn't have all the typedefs needed for standards
> compliance, so add a hack that adds all of the needed typedefs
> to be fully compliant to the standard.  Fixes broken libstdc++.

If you're touching VxWorks stdint.h perhaps you could also define the 
relevant target macros for GCC to have built-in knowledge of the types?  
This is needed for the Fortran C bindings to work correctly, at least, and 
ensures char16_t and char32_t (C11/C++11) are correct as well.  (You could 
then set use_gcc_stdint to "wrap" in config.gcc if you want to use GCC's 
stdint.h for freestanding compilations.)
rbmj - June 12, 2012, 8:14 p.m.
On 06/12/2012 11:47 AM, Joseph S. Myers wrote:
> On Wed, 6 Jun 2012, rbmj wrote:
>
>> The stdint.h doesn't have all the typedefs needed for standards
>> compliance, so add a hack that adds all of the needed typedefs
>> to be fully compliant to the standard.  Fixes broken libstdc++.
> If you're touching VxWorks stdint.h perhaps you could also define the
> relevant target macros for GCC to have built-in knowledge of the types?
> This is needed for the Fortran C bindings to work correctly, at least, and
> ensures char16_t and char32_t (C11/C++11) are correct as well.  (You could
> then set use_gcc_stdint to "wrap" in config.gcc if you want to use GCC's
> stdint.h for freestanding compilations.)
I would be happy to, but I'm not aware of what macros those are.  If you 
could point me to some documentation or explain to me what macros I need 
to define I'll update the patch.

Thanks,

Robert
Joseph S. Myers - June 12, 2012, 8:20 p.m.
On Tue, 12 Jun 2012, rbmj wrote:

> On 06/12/2012 11:47 AM, Joseph S. Myers wrote:
> > On Wed, 6 Jun 2012, rbmj wrote:
> > 
> > > The stdint.h doesn't have all the typedefs needed for standards
> > > compliance, so add a hack that adds all of the needed typedefs
> > > to be fully compliant to the standard.  Fixes broken libstdc++.
> > If you're touching VxWorks stdint.h perhaps you could also define the
> > relevant target macros for GCC to have built-in knowledge of the types?
> > This is needed for the Fortran C bindings to work correctly, at least, and
> > ensures char16_t and char32_t (C11/C++11) are correct as well.  (You could
> > then set use_gcc_stdint to "wrap" in config.gcc if you want to use GCC's
> > stdint.h for freestanding compilations.)
> I would be happy to, but I'm not aware of what macros those are.  If you could
> point me to some documentation or explain to me what macros I need to define
> I'll update the patch.

<http://gcc.gnu.org/ml/gcc/2009-04/msg00000.html> was my original 
announcement for target OS maintainers.  You should define the same set of 
macros as in gcc/config/glibc-stdint.h (but, obviously, to values 
appropriate to VxWorks), plus INTMAX_TYPE and UINTMAX_TYPE if the default 
values of those macros are wrong for VxWorks, and make sure all the 
c99-stdint-*.c tests pass.
rbmj - June 13, 2012, 3:40 p.m.
On 06/12/2012 04:20 PM, Joseph S. Myers wrote:
> On Tue, 12 Jun 2012, rbmj wrote:
>
>> On 06/12/2012 11:47 AM, Joseph S. Myers wrote:
>>> On Wed, 6 Jun 2012, rbmj wrote:
>>>
>>>> The stdint.h doesn't have all the typedefs needed for standards
>>>> compliance, so add a hack that adds all of the needed typedefs
>>>> to be fully compliant to the standard.  Fixes broken libstdc++.
>>> If you're touching VxWorks stdint.h perhaps you could also define the
>>> relevant target macros for GCC to have built-in knowledge of the types?
>>> This is needed for the Fortran C bindings to work correctly, at least, and
>>> ensures char16_t and char32_t (C11/C++11) are correct as well.  (You could
>>> then set use_gcc_stdint to "wrap" in config.gcc if you want to use GCC's
>>> stdint.h for freestanding compilations.)
>> I would be happy to, but I'm not aware of what macros those are.  If you could
>> point me to some documentation or explain to me what macros I need to define
>> I'll update the patch.
> <http://gcc.gnu.org/ml/gcc/2009-04/msg00000.html>  was my original
> announcement for target OS maintainers.  You should define the same set of
> macros as in gcc/config/glibc-stdint.h (but, obviously, to values
> appropriate to VxWorks), plus INTMAX_TYPE and UINTMAX_TYPE if the default
> values of those macros are wrong for VxWorks, and make sure all the
> c99-stdint-*.c tests pass.
>
Since u?int.*_t are already defined, would this work?  Or should I use 
the non-typedef'd versions?  Also, I'm not exactly sure how to run the 
regression tests with a cross compiler.  I'm still new to everything, 
bear with me :-)

     #define SIG_ATOMIC_TYPE "int"

     #define INT8_TYPE "int8_t"
     #define INT16_TYPE "int16_t"
     #define INT32_TYPE "int32_t"
     #define INT64_TYPE "int64_t"
     #define UINT8_TYPE "uint8_t"
     #define UINT16_TYPE "uint16_t"
     #define UINT32_TYPE "uint32_t"
     #define UINT64_TYPE "uint64_t"

     #define INT_LEAST8_TYPE "int_least8_t"
     #define INT_LEAST16_TYPE "int_least16_t"
     #define INT_LEAST32_TYPE "int_least32_t"
     #define INT_LEAST64_TYPE "int_least64_t"
     #define UINT_LEAST8_TYPE "uint_least8_t"
     #define UINT_LEAST16_TYPE "uint_least16_t"
     #define UINT_LEAST32_TYPE "uint_least32_t"
     #define UINT_LEAST64_TYPE "uint_least64_t"

     #define INT_FAST8_TYPE "int_fast8_t"
     #define INT_FAST16_TYPE "int_fast16_t"
     #define INT_FAST32_TYPE "int_fast32_t"
     #define INT_FAST64_TYPE "int_fast64_t"
     #define UINT_FAST8_TYPE "uint_fast8_t"
     #define UINT_FAST16_TYPE "uint_fast16_t"
     #define UINT_FAST32_TYPE "uint_fast32_t"
     #define UINT_FAST64_TYPE "uint_fast64_t"

     #define INTPTR_TYPE "intptr_t"
     #define UINTPTR_TYPE "uintptr_t"

Robert
Joseph S. Myers - June 13, 2012, 5:59 p.m.
On Wed, 13 Jun 2012, rbmj wrote:

> Since u?int.*_t are already defined, would this work?  Or should I use the
> non-typedef'd versions?  Also, I'm not exactly sure how to run the regression
> tests with a cross compiler.  I'm still new to everything, bear with me :-)

You have to use the non-typedef versions, with the keywords in the correct 
order - see the documentation of SIZE_TYPE in tm.texi for details.
rbmj - June 20, 2012, 7:36 p.m.
On 06/13/2012 01:59 PM, Joseph S. Myers wrote:
> On Wed, 13 Jun 2012, rbmj wrote:
>
>> Since u?int.*_t are already defined, would this work?  Or should I use the
>> non-typedef'd versions?  Also, I'm not exactly sure how to run the regression
>> tests with a cross compiler.  I'm still new to everything, bear with me :-)
> You have to use the non-typedef versions, with the keywords in the correct
> order - see the documentation of SIZE_TYPE in tm.texi for details.
>
OK, so I've looked everything over a few times, and I know that these 
are in types/vxTypesOld.h, which is not in the arch directory, so it 
*should* be architecture independent for vxWorks:

typedef    signed char    INT8;
typedef    signed short    INT16;
typedef    signed int    INT32;
typedef    signed long long INT64;

typedef    unsigned char    UINT8;
typedef    unsigned short    UINT16;
typedef    unsigned int    UINT32;
typedef    unsigned long long UINT64;

My issue is that I'm uncomfortable with this, as it seems *too* easy.  
With the number of architectures vxWorks supports, I'm highly skeptical 
that this actually works across all vxWorks targets.  Since I only work 
with ppc32 targets, perhaps somebody who has knowledge of other vxWorks 
ports could confirm or dismiss my fears.

Sorry for the amount of time it has taken me to respond.

Robert
Mike Stump - June 21, 2012, 6:27 a.m.
On Jun 20, 2012, at 12:36 PM, rbmj <rbmj@verizon.net> wrote:
> My issue is that I'm uncomfortable with this, as it seems *too* easy.

I'd just be comfortable with a stake in the ground and press forward.  I do think this covers most all the cases.

Patch

From a50ecd253f6e7fa4a6558ebce0578c5f48ccbc17 Mon Sep 17 00:00:00 2001
From: rbmj <rbmj@verizon.net>
Date: Mon, 4 Jun 2012 13:26:57 -0400
Subject: [PATCH 3/7] Add stdint.h wrapper for VxWorks.

The stdint.h doesn't have all the typedefs needed for standards
compliance, so add a hack that adds all of the needed typedefs
to be fully compliant to the standard.  Fixes broken libstdc++.

Changes:

	* fixincludes/inclhack.def: Added AAB_vxworks_stdint fix
---
 fixincludes/inclhack.def |   44 ++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 44 insertions(+), 0 deletions(-)

diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index d66b1cb..a7e49cd 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -396,6 +396,50 @@  fix = {
 
 
 /*
+ * Make VxWorks stdint.h a bit more compliant - add typedefs
+ */
+fix = {
+	hackname	= AAB_vxworks_stdint;
+	files		= stdint.h;
+	mach		= "*-*-vxworks*";
+	
+	replace		= <<- _EndOfHeader_
+	#ifndef _STDINT_H
+	#define _STDINT_H
+	/* get int*_t, uint*_t */
+	#include <types/vxTypes.h>
+
+	typedef long intptr_t;
+	typedef unsigned long uintptr_t;
+
+	typedef int64_t intmax_t;
+	typedef uint64_t uintmax_t;
+
+	typedef int8_t int_least8_t;
+	typedef int16_t int_least16_t;
+	typedef int32_t int_least32_t;
+	typedef int64_t int_least64_t;
+
+	typedef uint8_t uint_least8_t;
+	typedef uint16_t uint_least16_t;
+	typedef uint32_t uint_least32_t;
+	typedef uint64_t uint_least64_t;
+
+	typedef int8_t int_fast8_t;
+	typedef int int_fast16_t;
+	typedef int32_t int_fast32_t;
+	typedef int64_t int_fast64_t;
+
+	typedef uint8_t uint_fast8_t;
+	typedef unsigned int uint_fast16_t;
+	typedef uint32_t uint_fast32_t;
+	typedef uint64_t uint_fast64_t;
+	#endif
+	_EndOfHeader_;
+};
+
+
+/*
  * complex.h on AIX 5 and AIX 6 define _Complex_I and I in terms of __I,
  * which only is provided by AIX xlc C99.
  */
-- 
1.7.5.4