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

login
register
mail settings
Submitter rbmj
Date June 25, 2012, 7:09 p.m.
Message ID <4FE8B757.7020909@verizon.net>
Download mbox | patch
Permalink /patch/167228/
State New
Headers show

Comments

rbmj - June 25, 2012, 7:09 p.m.
On 06/21/2012 02:27 AM, Mike Stump wrote:
> 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.
>
With that in mind, then, here's a new patch over my original patch (i.e. 
both are necessary).  Let me know if this is what is needed or if I'm 
still mistaken.

I also do not know how to run the test suite for the target system 
(powerpc-wrs-vxworks).  I would think some sort of powerpc simulator, 
but I don't have a firmware image for VxWorks - just headers and 
embedded hardware.

Modified:
     *gcc/config.gcc: Set use_gcc_stdint to 'wrap' for
      vxworks targets.
     *fixincludes/inclhack.def (AAB_vxworks_stdint): add
      #defines to make GCC aware of VxWorks stdint types
     *fixincludes/fixincl.x: Regenerate

Robert Mason
Mike Stump - June 25, 2012, 8:02 p.m.
On Jun 25, 2012, at 12:09 PM, rbmj wrote:
> I also do not know how to run the test suite for the target system (powerpc-wrs-vxworks).  I would think some sort of powerpc simulator, but I don't have a firmware image for VxWorks - just headers and embedded hardware.

To test well, you need to be able to compile and run code.  So, the question is, can you do that, or not?  If you can, then you have what you need to test.  If you cannot do that, then you cannot test well.  If you can compile, then you can test the compile time tests, but you'll miss out on all runtime tests.
rbmj - June 25, 2012, 8:15 p.m.
On 06/25/2012 04:02 PM, Mike Stump wrote:
> On Jun 25, 2012, at 12:09 PM, rbmj wrote:
>> I also do not know how to run the test suite for the target system (powerpc-wrs-vxworks).  I would think some sort of powerpc simulator, but I don't have a firmware image for VxWorks - just headers and embedded hardware.
> To test well, you need to be able to compile and run code.  So, the question is, can you do that, or not?  If you can, then you have what you need to test.  If you cannot do that, then you cannot test well.  If you can compile, then you can test the compile time tests, but you'll miss out on all runtime tests.
>
Well, I know that I need to be able to compile and run code.  I would 
guess (/hope) that the testsuite is automated though, but I can't use 
that if I need to use my own custom buildscripts in order to generate 
executables (can I?).  Furthermore, I looked in those files 
(gcc/testsuite/gcc.dg/c99-stdint* - are these correct?) and I can't find 
any entry point.

If it helps, I can compile/run code.  I know that the original 
fixincludes patches I had compiled and ran code as well - I built my 
project and successfully ran it.  The problem is I don't exactly know 
the method.  Also, my classes have finished so I no longer have access 
to a target :-/

Robert Mason
Mike Stump - June 25, 2012, 10:42 p.m.
On Jun 25, 2012, at 1:15 PM, rbmj wrote:
> On 06/25/2012 04:02 PM, Mike Stump wrote:
>> On Jun 25, 2012, at 12:09 PM, rbmj wrote:
>>> I also do not know how to run the test suite for the target system (powerpc-wrs-vxworks).  I would think some sort of powerpc simulator, but I don't have a firmware image for VxWorks - just headers and embedded hardware.
>> To test well, you need to be able to compile and run code.  So, the question is, can you do that, or not?  If you can, then you have what you need to test.  If you cannot do that, then you cannot test well.  If you can compile, then you can test the compile time tests, but you'll miss out on all runtime tests.
>> 
> Well, I know that I need to be able to compile and run code.  I would guess (/hope) that the testsuite is automated though,

It is.

> but I can't use that if I need to use my own custom buildscripts in order to generate executables (can I?).

Yes, you can use it.

> Furthermore, I looked in those files (gcc/testsuite/gcc.dg/c99-stdint* - are these correct?) and I can't find any entry point.

Lots of tests don't require main.  A class that does require main are C runtime tests.

> If it helps, I can compile/run code.  I know that the original fixincludes patches I had compiled and ran code as well - I built my project and successfully ran it.  The problem is I don't exactly know the method.  Also, my classes have finished so I no longer have access to a target :-/

Ah, if no access, then, no runtime testing.  You can still do compile time testing, if you want.

An easier task might be to ask someone that has a VxWorks testing setup to test for you, there might be someone on the list that has one.

Patch

From 534222784011172403801a1617d67dba174c8441 Mon Sep 17 00:00:00 2001
From: rbmj <rbmj@verizon.net>
Date: Wed, 13 Jun 2012 11:24:01 -0400
Subject: [PATCH] Make GCC aware of VxWorks stdint types.

Modified:
	*gcc/config.gcc: Set use_gcc_stdint to 'wrap' for
	 vxworks targets.
	*fixincludes/inclhack.def (AAB_vxworks_stdint): add
	 #defines to make GCC aware of VxWorks stdint types
	*fixincludes/fixincl.x: Regenerate
---
 fixincludes/inclhack.def |   32 ++++++++++++++++++++++++++++++++
 gcc/config.gcc           |    1 +
 2 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index 063158c..d122b6d 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -434,6 +434,38 @@  fix = {
 	typedef unsigned int uint_fast16_t;
 	typedef uint32_t uint_fast32_t;
 	typedef uint64_t uint_fast64_t;
+	
+	#define SIG_ATOMIC_TYPE "int"
+
+	#define INT8_TYPE "signed char"
+	#define INT16_TYPE "signed short"
+	#define INT32_TYPE "signed int"
+	#define INT64_TYPE "signed long long"
+	#define UINT8_TYPE "unsigned char"
+	#define UINT16_TYPE "unsigned short"
+	#define UINT32_TYPE "unsigned int"
+	#define UINT64_TYPE "unsigned long long"
+
+	#define INT_LEAST8_TYPE "signed char"
+	#define INT_LEAST16_TYPE "signed short"
+	#define INT_LEAST32_TYPE "signed int"
+	#define INT_LEAST64_TYPE "signed long long"
+	#define UINT_LEAST8_TYPE "unsigned char"
+	#define UINT_LEAST16_TYPE "unsigned short"
+	#define UINT_LEAST32_TYPE "unsigned int"
+	#define UINT_LEAST64_TYPE "unsigned long long"
+
+	#define INT_FAST8_TYPE "signed char"
+	#define INT_FAST16_TYPE "signed int"
+	#define INT_FAST32_TYPE "signed int"
+	#define INT_FAST64_TYPE "signed long long"
+	#define UINT_FAST8_TYPE "unsigned char"
+	#define UINT_FAST16_TYPE "unsigned int"
+	#define UINT_FAST32_TYPE "unsigned int"
+	#define UINT_FAST64_TYPE "unsigned long long"
+
+	#define INTPTR_TYPE "long"
+	#define UINTPTR_TYPE "unsigned long"
 	#endif
 	_EndOfHeader_;
 };
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 7ec184c..11369d3 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -771,6 +771,7 @@  case ${target} in
   fi
   ;;
 *-*-vxworks*)
+  use_gcc_stdint=wrap
   tmake_file=t-vxworks
   xm_defines=POSIX
   extra_options="${extra_options} vxworks.opt"
-- 
1.7.5.4