| Message ID | 4FE8B757.7020909@verizon.net |
|---|---|
| State | New |
| Headers | show |
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.
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
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.
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