[PATCH] Fixincludes/VxWorks

[PATCH] Fixincludes/VxWorks

[rbmj]

Hi everyone,

This patch series is the result of this [1] thread about fixincludes on 
VxWorks.  It resolves bugs 53457 and 53378, and a few other issues that 
previously required manual intervention to fix for VxWorks header files.

The fixes are tested and work correctly both with make stmp-fixinc in 
gcc and make check in fixincludes.

The initial hack (which is not the most elegant solution but isn't quite 
as pessimal as disabling everything entirely) does not break anything on 
both a cross build to powerpc-wrs-vxworks and a bootstrap build on 
x86_64-unknown-linux-gnu.

Any comments are appreciated.  Also, I don't have commit access.

CC'ing Nathan Sidwell and Bruce Korb, as MAINTAINERS says you're the 
VxWorks and fixincludes maintainers, respectively.

Thanks,

Robert Mason

[1] http://gcc.gnu.org/ml/gcc-help/2012-05/msg00172.html

[PATCH 1/7] Add ability to skip the machine_name fixincludes fix.

[rbmj]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

On some platforms, machine_name is overzealous, or even breaks things.
This patch adds the functionality to skip the machine_name 'fix' by
giving it an empty macro list.

gcc/configure: Regenerate
---
  fixincludes/mkfixinc.sh |    1 -
  gcc/Makefile.in         |   15 +++++++++++----
  gcc/configure.ac        |   14 ++++++++++++++
  3 files changed, 25 insertions(+), 5 deletions(-)


[-- Attachment #2: 0001-Add-ability-to-skip-the-machine_name-fixincludes-fix.patch --]
[-- Type: text/x-patch, Size: 2798 bytes --]

From 76bc7ef3c6a21502dd7af5b4427080b2cdd3cdd9 Mon Sep 17 00:00:00 2001
From: rbmj <rbmj@verizon.net>
Date: Wed, 30 May 2012 08:16:57 -0400
Subject: [PATCH 1/7] Add ability to skip the machine_name fixincludes fix.

On some platforms, machine_name is overzealous, or even breaks things.
This patch adds the functionality to skip the machine_name 'fix' by
giving it an empty macro list.

gcc/configure: Regenerate
---
 fixincludes/mkfixinc.sh |    1 -
 gcc/Makefile.in         |   15 +++++++++++----
 gcc/configure.ac        |   14 ++++++++++++++
 3 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/fixincludes/mkfixinc.sh b/fixincludes/mkfixinc.sh
index 89e8ab7..6653fed 100755
--- a/fixincludes/mkfixinc.sh
+++ b/fixincludes/mkfixinc.sh
@@ -15,7 +15,6 @@ case $machine in
     i?86-*-mingw32* | \
     x86_64-*-mingw32* | \
     i?86-*-interix* | \
-    *-*-vxworks* | \
     powerpc-*-eabisim* | \
     powerpc-*-eabi*    | \
     powerpc-*-rtems*   | \
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 887a56e..9f0e78e 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -245,6 +245,9 @@ LINKER_FLAGS = $(CFLAGS)
 endif
 endif
 
+# Whether or not to run the machine_name fixincludes fix
+SKIP_MACHINE_NAME_FIX = @skip_machine_name_fix@
+
 # -------------------------------------------
 # Programs which operate on the build machine
 # -------------------------------------------
@@ -4131,10 +4134,14 @@ install-gcc-tooldir:
 
 macro_list: s-macro_list; @true
 s-macro_list : $(GCC_PASSES)
-	echo | $(GCC_FOR_TARGET) -E -dM - | \
-	  sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' \
-		 -e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \
-	  sort -u > tmp-macro_list
+	@if test "$(SKIP_MACHINE_NAME_FIX)" != "yes" ; then \
+		echo | $(GCC_FOR_TARGET) -E -dM - | \
+			sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' \
+				-e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \
+			sort -u > tmp-macro_list ; \
+	else \
+		echo > tmp-macro_list ; \
+	fi
 	$(SHELL) $(srcdir)/../move-if-change tmp-macro_list macro_list
 	$(STAMP) s-macro_list
 
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 22dab55..aebb351 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -5142,6 +5142,20 @@ if test x"${LINKER_HASH_STYLE}" != x; then
                                          [The linker hash style])
 fi
 
+# Check whether to enable the fixincludes machine_name hack on this platform
+case "${target}" in
+    *-*-vxworks*)
+        skip_machine_name_fix="yes"
+        ;;
+    *)
+        # Note that some platforms have fixincludes disabled by default so
+        # this will make no difference
+        skip_machine_name_fix="no"
+        ;;
+esac
+AC_SUBST(skip_machine_name_fix)
+
+
 # Configure the subdirectories
 # AC_CONFIG_SUBDIRS($subdirs)
 
-- 
1.7.5.4

[PATCH 2/7] Added assert fixinclude hack for VxWorks.

[rbmj]

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

VxWorks's assert.h relies on adjacent string tokens being joined,
and uses macros for some of the strings (e.g. __FILE__).  However,
it does not put a space after the end quote and before the macro,
so instead of replacing the macro, gcc >= 4.7.x thinks it's a
user-defined literal token, and since the lookup obviously fails,
compilation of libstdc++ dies.

Changes:

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

[-- Attachment #2: 0002-Added-assert-fixinclude-hack-for-VxWorks.patch --]
[-- Type: text/x-patch, Size: 1835 bytes --]

From d2cbe2a8f546abf5713e8a6ed614ef2eac1f749b Mon Sep 17 00:00:00 2001
From: rbmj <rbmj@verizon.net>
Date: Mon, 4 Jun 2012 13:18:10 -0400
Subject: [PATCH 2/7] Added assert fixinclude hack for VxWorks.

VxWorks's assert.h relies on adjacent string tokens being joined,
and uses macros for some of the strings (e.g. __FILE__).  However,
it does not put a space after the end quote and before the macro,
so instead of replacing the macro, gcc >= 4.7.x thinks it's a
user-defined literal token, and since the lookup obviously fails,
compilation of libstdc++ dies.

Changes:

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

diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index 8a26f28..d66b1cb 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -354,6 +354,46 @@ fix = {
 	_EndOfHeader_;
 };
 
+/*
+ * Fix assert.h on VxWorks:
+ */
+fix = {
+	hackname	= AAB_vxworks_assert;
+	files		= assert.h;
+	mach		= "*-*-vxworks*";
+	
+	replace		= <<- _EndOfHeader_
+	#ifndef _ASSERT_H
+	#define _ASSERT_H
+
+	#ifdef assert
+	#undef assert
+	#endif
+
+	#if defined(__STDC__) || defined(__cplusplus)
+	extern void __assert (const char*);
+	#else
+	extern void __assert ();
+	#endif
+
+	#ifdef NDEBUG
+	#define assert(ign) ((void)0)
+	#else
+
+	#define ASSERT_STRINGIFY(str) ASSERT_STRINGIFY_HELPER(str)
+	#define ASSERT_STRINGIFY_HELPER(str) #str
+
+	#define assert(test) ((void) \
+		((test) ? ((void)0) : \
+		__assert("Assertion failed: " ASSERT_STRINGIFY(test) ", file " \
+		__FILE__ ", line " ASSERT_STRINGIFY(__LINE__) "\n")))
+
+	#endif
+
+	#endif
+	_EndOfHeader_;
+};
+
 
 /*
  * complex.h on AIX 5 and AIX 6 define _Complex_I and I in terms of __I,
-- 
1.7.5.4

[PATCH 4/7] Add unistd.h wrapper for VxWorks.

[rbmj]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

On VxWorks, unistd.h doesn't define everything it should, like
read/write, etc.  This wrapper adds the things it should define
so everything can be compliant and compile correctly without
manual modification.

Changes:

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


[-- Attachment #2: 0004-Add-unistd.h-wrapper-for-VxWorks.patch --]
[-- Type: text/x-patch, Size: 1403 bytes --]

From e389d506193e80713b9511713a220867159f5a8e Mon Sep 17 00:00:00 2001
From: rbmj <rbmj@verizon.net>
Date: Mon, 4 Jun 2012 14:02:08 -0400
Subject: [PATCH 4/7] Add unistd.h wrapper for VxWorks.

On VxWorks, unistd.h doesn't define everything it should, like
read/write, etc.  This wrapper adds the things it should define
so everything can be compliant and compile correctly without
manual modification.

Changes:

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

diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index a7e49cd..54a8b8d 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -438,6 +438,32 @@ fix = {
 	_EndOfHeader_;
 };
 
+/*
+ *  This hack makes makes unistd.h more POSIX-compliant on VxWorks
+ */
+fix = {
+	hackname	= AAB_vxworks_unistd;
+	files	   = unistd.h;
+	mach		= "*-*-vxworks*";
+	
+	replace		= <<- _EndOfHeader_
+	#ifndef _UNISTD_H
+	#define _UNISTD_H
+	#include_next <unistd.h>
+	#include <ioLib.h>
+	#ifndef STDIN_FILENO
+	#define STDIN_FILENO 0
+	#endif
+	#ifndef STDOUT_FILENO
+	#define STDOUT_FILENO 1
+	#endif
+	#ifndef STDERR_FILENO
+	#define STDERR_FILENO 2
+	#endif
+	#endif /* _UNISTD_H */
+	_EndOfHeader_;
+};
+
 
 /*
  * complex.h on AIX 5 and AIX 6 define _Complex_I and I in terms of __I,
-- 
1.7.5.4

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

[rbmj]

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]

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(-)


[-- Attachment #2: 0003-Add-stdint.h-wrapper-for-VxWorks.patch --]
[-- Type: text/x-patch, Size: 1900 bytes --]

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

[PATCH 5/7] Add fix to prevent accidental inclusion of regs.h on, VxWorks.

[rbmj]

[-- Attachment #1: Type: text/plain, Size: 384 bytes --]

VxWorks has it's own regs.h that conflicts with GCC's regs.h, so
just make any replace any references to regs.h in VxWorks with
references to arch/../regs.h, which includes the VxWorks header,
not GCC's header.

Changes:

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


[-- Attachment #2: 0005-Add-fix-to-prevent-accidental-inclusion-of-regs.h-on.patch --]
[-- Type: text/x-patch, Size: 1200 bytes --]

From 2aa0effcb0e5b617e099a8390ce97677ba27a49a Mon Sep 17 00:00:00 2001
From: rbmj <rbmj@verizon.net>
Date: Mon, 4 Jun 2012 14:07:32 -0400
Subject: [PATCH 5/7] Add fix to prevent accidental inclusion of regs.h on
 VxWorks.

VxWorks has it's own regs.h that conflicts with GCC's regs.h, so
just make any replace any references to regs.h in VxWorks with
references to arch/../regs.h, which includes the VxWorks header,
not GCC's header.

Changes:

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

diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index 54a8b8d..a258f10 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -4473,6 +4473,20 @@ fix = {
     "# define\t__INCstath <sys/stat.h>";
 };
 
+/*
+ *  Make it so VxWorks does not include gcc/regs.h accidentally
+ */
+fix = {
+	hackname	= vxworks_regs;
+	mach		= "*-*-vxworks*";
+	
+	select		= "#[\t ]*include[\t ]+<regs.h>";
+	c_fix		= format;
+	c_fix_arg	= "#include <arch/../regs.h>";
+	
+	test_text	= "#include <regs.h>\n";
+};
+
 
 /*
  *  Another bad dependency in VxWorks 5.2 <time.h>.
-- 
1.7.5.4

[PATCH 6/7] Add hack for ioctl() on VxWorks.

[rbmj]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

ioctl() is supposed to be variadic, but VxWorks only has a three
argument version with the third argument of type int.  This messes
up when the third argument is not implicitly convertible to int.
This adds a macro which wraps around ioctl() and explicitly casts
the third argument to an int.

Changes:

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


[-- Attachment #2: 0006-Add-hack-for-ioctl-on-VxWorks.patch --]
[-- Type: text/x-patch, Size: 1439 bytes --]

From 3a52d77fdbf4c422a1e641402794ce8eda47f410 Mon Sep 17 00:00:00 2001
From: rbmj <rbmj@verizon.net>
Date: Mon, 4 Jun 2012 14:16:26 -0400
Subject: [PATCH 6/7] Add hack for ioctl() on VxWorks.

ioctl() is supposed to be variadic, but VxWorks only has a three
argument version with the third argument of type int.  This messes
up when the third argument is not implicitly convertible to int.
This adds a macro which wraps around ioctl() and explicitly casts
the third argument to an int.

Changes:

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

diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index a258f10..7863dbe 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -4440,6 +4440,22 @@ fix = {
     "#endif /* __GNUC_TYPEOF_FEATURE_BROKEN_USE_DEFAULT_UNTIL_FIXED__ */\n";
 };
 
+/*
+ *  Wrap VxWorks ioctl to keep everything pretty
+ */
+fix = {
+	hackname	= vxworks_ioctl_macro;
+	files	   	= ioLib.h;
+	mach		= "*-*-vxworks*";
+
+	c_fix		= format;
+	c_fix_arg	= "%0\n"
+		"#define ioctl(fd, func, arg) ((ioctl)((fd), (func), ((int)(arg))))\n";
+	c_fix_arg	= "extern[\t ]+int[\t ]+ioctl[\t ]*\([\t ,[:alnum:]]\);";
+	
+	test_text	= "extern int ioctl ( int asdf1234, int jkl , int qwerty ) ;";
+};
+
 
 /*
  *  Fix VxWorks <time.h> to not require including <vxTypes.h>.
-- 
1.7.5.4

[PATCH 7/7] Add fix to make write() const correct on VxWorks

[rbmj]

[-- Attachment #1: Type: text/plain, Size: 428 bytes --]

VxWorks' write() takes its second argument as non-const, but the
compiler complains if one tries to pass a const pointer to it.
This simply changes the prototype to say it is const so everything
works.

Changes:

     * fixincludes/inclhack.def:  Added vxworks_write_const fix
     * fixincludes/fixincl.x:  Regenerate
---
  fixincludes/inclhack.def |   17 +++++++++++++++++
  1 files changed, 17 insertions(+), 0 deletions(-)


[-- Attachment #2: 0007-Add-fix-to-make-write-const-correct-on-VxWorks.patch --]
[-- Type: text/x-patch, Size: 1409 bytes --]

From e30ed6b06659f1d88fc76ea6fe83408bc6d3060c Mon Sep 17 00:00:00 2001
From: rbmj <rbmj@verizon.net>
Date: Mon, 4 Jun 2012 14:21:37 -0400
Subject: [PATCH 7/7] Add fix to make write() const correct on VxWorks

VxWorks' write() takes its second argument as non-const, but the
compiler complains if one tries to pass a const pointer to it.
This simply changes the prototype to say it is const so everything
works.

Changes:

	* fixincludes/inclhack.def:  Added vxworks_write_const fix
	* fixincludes/fixincl.x:  Regenerate
---
 fixincludes/inclhack.def |   17 +++++++++++++++++
 1 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index 7863dbe..063158c 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -4530,6 +4530,23 @@ fix = {
                 "#define VOIDFUNCPTR (void(*)())";
 };
 
+/*
+ *  This hack makes write const-correct on VxWorks
+ */
+fix = {
+	hackname	= vxworks_write_const;
+	files		= ioLib.h;
+	mach		= "*-*-vxworks*";
+
+	c_fix		= format;
+	c_fix_arg	= "extern int  write (int, const char*, size_t);";
+	c_fix_arg	= "extern[\t ]+int[\t ]+write[\t ]*\("
+		"[\t ]*int[\t ]*,"
+		"[\t ]*char[\t ]*\*[\t ]*,"
+		"[\t ]*size_t[\t ]*\)[\t ]*;";
+	
+	test_text	= "extern int write ( int , char * , size_t ) ;";
+};
 
 /*
  *  There are several name conflicts with C++ reserved words in X11 header
-- 
1.7.5.4

Re: [PATCH] Fixincludes/VxWorks

[Bruce Korb]

Please read README and look to inclhack.def for examples
approximating the kind of testing you are interested in doing.
"test -r vxWorks.h" is a pointless test if you configure the fix
to apply only to a file named vxWorks.h.

On Wed, Jun 6, 2012 at 9:33 AM, rbmj <rbmj@verizon.net> wrote:
> Hi everyone,
>
> This patch series is the result of this [1] thread about fixincludes on
> VxWorks.  It resolves bugs 53457 and 53378, and a few other issues that
> previously required manual intervention to fix for VxWorks header files.
>
> The fixes are tested and work correctly both with make stmp-fixinc in gcc
> and make check in fixincludes.
>
> The initial hack (which is not the most elegant solution but isn't quite as
> pessimal as disabling everything entirely) does not break anything on both a
> cross build to powerpc-wrs-vxworks and a bootstrap build on
> x86_64-unknown-linux-gnu.
>
> Any comments are appreciated.  Also, I don't have commit access.
>
> CC'ing Nathan Sidwell and Bruce Korb, as MAINTAINERS says you're the VxWorks
> and fixincludes maintainers, respectively.
>
> Thanks,
>
> Robert Mason
>
> [1] http://gcc.gnu.org/ml/gcc-help/2012-05/msg00172.html

Re: [PATCH] Fixincludes/VxWorks

[Bruce Korb]

On 06/06/12 09:33, rbmj wrote:
> Hi everyone,

OK, I'm slow.  I just woke up from a late night.  "test -r vxWorks.h"
is the mechanism to ensure that tests only fire on a vxworks platform.
Seems a bit obscure, but if it is easier than other mechanisms, then
fine.  I do think a "mach" test would be much more straight forward:

     * mach   - Match the output of config.guess against a series of fnmatch
                patterns.  It must match at least one of the patterns, unless
                "not-machine" has also been specified.  In that case, the
                config.guess output must not match any of the patterns.

(from the README file)  It would remove any need for relying on side
effects in the "test-text":

     test_text   = "`touch vxWorks.h`"
         "extern int write ( int , char * , size_t ) ;";

There is no guarantee that that will work.  It only works because in the
construction of the test, the text gets passed through shell interpretation
at some point.  It is not required that that happen.  To do what you
want, you'd need to use this:

     test-text = `touch vxWorks.h
          echo "extern int write ( int , char * , size_t ) ;"`;

and even then, it should be researched as to whether or not you need
to prefix the touched file name with "${SRCDIR}/" because I don't remember.
I still think:

     mach = "*-*-vxworks*";

is more straight forward, and you can then eliminate the touchy vxWorks.h
thingy.

Re: [PATCH] Fixincludes/VxWorks

[rbmj]

On 06/06/2012 01:11 PM, Bruce Korb wrote:
> On 06/06/12 09:33, rbmj wrote:
>> Hi everyone,
>
> OK, I'm slow.  I just woke up from a late night.  "test -r vxWorks.h"
> is the mechanism to ensure that tests only fire on a vxworks platform.
> Seems a bit obscure, but if it is easier than other mechanisms, then
> fine.  I do think a "mach" test would be much more straight forward:
>
>     * mach   - Match the output of config.guess against a series of 
> fnmatch
>                patterns.  It must match at least one of the patterns, 
> unless
>                "not-machine" has also been specified.  In that case, the
>                config.guess output must not match any of the patterns.
>
> <snip />
> and even then, it should be researched as to whether or not you need
> to prefix the touched file name with "${SRCDIR}/" because I don't 
> remember.
> I still think:
>
>     mach = "*-*-vxworks*";
>
> is more straight forward, and you can then eliminate the touchy vxWorks.h
> thingy.
>
The version that I posted in the original thread is not the latest 
version.  The patches that I've sent to -patches all use the mach test, 
not the test idiom.

Robert Mason

Re: [PATCH] Fixincludes/VxWorks

[Nathan Sidwell]

On 06/06/12 17:33, rbmj wrote:
> Hi everyone,
>
> This patch series is the result of this [1] thread about fixincludes on VxWorks.
> It resolves bugs 53457 and 53378, and a few other issues that previously
> required manual intervention to fix for VxWorks header files.

 From a vxworks POV these all look ok.

nathan

Re: [PATCH] Fixincludes/VxWorks

[Bruce Korb]

On Sun, Jun 10, 2012 at 10:57 AM, Nathan Sidwell <nathan@acm.org> wrote:
> On 06/06/12 17:33, rbmj wrote:
>>
>> Hi everyone,
>>
>> This patch series is the result of this [1] thread about fixincludes on
>> VxWorks.
>> It resolves bugs 53457 and 53378, and a few other issues that previously
>> required manual intervention to fix for VxWorks header files.
>
>
> From a vxworks POV these all look ok.

Oh, from fixincludes, too.

Re: [PATCH] Fixincludes/VxWorks

[rbmj]

On 06/10/2012 02:38 PM, Bruce Korb wrote:
> On Sun, Jun 10, 2012 at 10:57 AM, Nathan Sidwell<nathan@acm.org>  wrote:
>> On 06/06/12 17:33, rbmj wrote:
>>> Hi everyone,
>>>
>>> This patch series is the result of this [1] thread about fixincludes on
>>> VxWorks.
>>> It resolves bugs 53457 and 53378, and a few other issues that previously
>>> required manual intervention to fix for VxWorks header files.
>>
>>  From a vxworks POV these all look ok.
> Oh, from fixincludes, too.
>
Could somebody please commit this?  I don't have access.

Thanks,

Robert Mason

Re: [PATCH 3/7] Add stdint.h wrapper for VxWorks.

[Joseph S. Myers]

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.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH 3/7] Add stdint.h wrapper for VxWorks.

[rbmj]

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

Re: [PATCH 3/7] Add stdint.h wrapper for VxWorks.

[Joseph S. Myers]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH 3/7] Add stdint.h wrapper for VxWorks.

[rbmj]

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

Re: [PATCH 3/7] Add stdint.h wrapper for VxWorks.

[Joseph S. Myers]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH 3/7] Add stdint.h wrapper for VxWorks.

[rbmj]

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

Re: [PATCH 3/7] Add stdint.h wrapper for VxWorks.

[Mike Stump]

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.

Re: [PATCH 3/7] Add stdint.h wrapper for VxWorks.

[rbmj]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

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

[-- Attachment #2: stdint.patch --]
[-- Type: text/x-patch, Size: 2303 bytes --]

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

Re: [PATCH 3/7] Add stdint.h wrapper for VxWorks.

[Mike Stump]

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.

Re: [PATCH 3/7] Add stdint.h wrapper for VxWorks.

[rbmj]

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

Re: [PATCH 3/7] Add stdint.h wrapper for VxWorks.

[Mike Stump]

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.