Re: Unreviewed Patch
On 25-Feb-14 01:21, Jeff Law wrote: I think this should be queued until after 4.9 branches. It's adding a new capability (posix threading on vxworks), not fixing a bug and certainly not fixing a regression AFAICT. Fair enough. It just seems somewhat trivial to me, as it doesn't add any functional code, just some #defines and a stub. Bug could be "compilation of pthread-based gthreads disallowed on platform (vxworks) supporting pthreads", but that's a stretch, so if you want I can resubmit it after 4.9 branches. I just think that users should be able to compile targeting pthreads if they know that their target will support it, especially if it enables additional capabilities (e.g. C++11 std::thread).
Unreviewed Patch
Hi all, Just a ping, I haven't gotten anything back on this patch: http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00621.html Thanks!
[VxWorks] Allow --enable-threads=posix
Some builds of VxWorks have a pthread compatibility layer. This patch
allows one to compile GCC to use the pthread compatibility layer instead
of the native vxworks threads.
I wrote this patch to get the c++11 threads to work - the vxworks native
support don't implement all the necessary features, and it was much
easier to use posix threads rather than add the necessary native thread
support.
I do not have commit access, so someone would have to apply this for me.
Everything builds correctly, and users report success.
It does dirty up ghtr-posix.h a bit, but it doesn't appear to be too
bad, and there's other platform-specific hacks in that file already.
Thanks,
R Blair Mason
>From 2cf34e06f47345884f234bb870714ed2896745a6 Mon Sep 17 00:00:00 2001
From: rbmj
Date: Sat, 4 Jan 2014 09:11:02 -0500
Subject: [PATCH] Allowed posix as a thread option for vxworks
Note: VxWorks defines all of the _POSIX_TIMERS functions, but doesn't
define the macro. Configure looks for the _POSIX_TIMERS macro when
checking for these functions. This seems strange to me. It seems like
if the try_compile can find them, then everything should be fine.
I'm not an expert though, and acinclude.m4 notes that there is a similar
situation for darwin, so I'll just let it be this way for now.
---
gcc/config.gcc | 1 +
libgcc/config.host | 8 ++
libgcc/config/t-vxworks-pthread | 14 +++
libgcc/gthr-posix.h | 38 -
libstdc++-v3/config/os/vxworks/os_defines.h | 3 +++
5 files changed, 63 insertions(+), 1 deletion(-)
create mode 100644 libgcc/config/t-vxworks-pthread
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 92d57dd..3fd9bb5 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -804,6 +804,7 @@ case ${target} in
case ${enable_threads} in
no) ;;
"" | yes | vxworks) thread_file='vxworks' ;;
+posix) thread_file='posix' ;;
*) echo 'Unknown thread configuration for VxWorks'; exit 1 ;;
esac
;;
diff --git a/libgcc/config.host b/libgcc/config.host
index 259c9a7..21471db 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -261,6 +261,14 @@ case ${host} in
;;
*-*-vxworks*)
tmake_file=t-vxworks
+ case ${target_thread_file} in
+vxworks)
+ tmake_file=t-vxworks
+ ;;
+posix)
+ tmake_file=t-vxworks-pthread
+ ;;
+ esac
;;
*-*-elf)
extra_parts="crtbegin.o crtend.o"
diff --git a/libgcc/config/t-vxworks-pthread b/libgcc/config/t-vxworks-pthread
new file mode 100644
index 000..4e538f9
--- /dev/null
+++ b/libgcc/config/t-vxworks-pthread
@@ -0,0 +1,14 @@
+# Don't build libgcc.a with debug info
+LIBGCC2_DEBUG_CFLAGS =
+
+# No out-of line help needed
+LIB2ADD =
+
+# This ensures that the correct target headers are used; some
+# VxWorks system headers have names that collide with GCC's
+# internal (host) headers, e.g. regs.h.
+LIBGCC2_INCLUDES = -nostdinc -I \
+ `case "/$$(MULTIDIR)" in \
+ */mrtp*) echo $(WIND_USR)/h ;; \
+ *) echo $(WIND_BASE)/target/h ;; \
+ esac`
diff --git a/libgcc/gthr-posix.h b/libgcc/gthr-posix.h
index f0d8cd7..b6a6069 100644
--- a/libgcc/gthr-posix.h
+++ b/libgcc/gthr-posix.h
@@ -33,6 +33,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
#define __GTHREADS_CXX0X 1
#include
+/* For timespec, in case pthread.h doesn't include this */
+#include
+/* For sched_yield, in case pthread.h doesn't include this */
+#include
#if ((defined(_LIBOBJC) || defined(_LIBOBJC_WEAK)) \
|| !defined(_GTHREAD_USE_MUTEX_TIMEDLOCK))
@@ -130,10 +134,42 @@ __gthrw(pthread_cond_destroy)
__gthrw(pthread_key_create)
__gthrw(pthread_key_delete)
+
__gthrw(pthread_mutexattr_init)
-__gthrw(pthread_mutexattr_settype)
__gthrw(pthread_mutexattr_destroy)
+/* VxWorks does not define pthread_mutexattr_settype itself, and we need
+ the constants and a prototype to be defined somewhere so the rest of
+ this file will compile (they will be ignored) */
+#ifdef __VXWORKS__
+
+#define ATTRIBUTE_UNUSED __attribute__((unused))
+
+static inline int
+__gthrw_pthread_mutexattr_settype (pthread_mutexattr_t *a ATTRIBUTE_UNUSED, int t ATTRIBUTE_UNUSED)
+{
+ /* TODO: It might be possible to override the mutex machinery to
+ simulate non-recursive mutexes, but this doesn't seem to be
+ necessary because all vxworks mutexes are recursive, and recursive
+ mutexes cover the most general case. */
+ return 0;
+}
+
+#undef ATTRIBUTE_UNUSED
+
+#define PTHREAD_MUTEX_NORMAL 0
+#define PTHREAD_MUTEX_ERRORCHECK 0
+#define PTHREAD_MUTEX_RECURSIVE 0
+#define PTHREAD_MUTEX_DEFAULT 0
+
+#else
+
+__gthrw(pthread_mutexattr_settype)
+
+#endif
+
+
+
#if defined(_LIBOBJC) || defined(_LIBOBJC_WEAK)
/* Objective-C. */
diff --git a/libstdc++-v3/config/os/vxworks/os_defines.h b/libst
Re: [PING^5] PR 54805: __gthread_tsd* in vxlib-tls.c
It looks like this message didn't go through; if you get this multiple times I apologize. I've been having issues so I don't trust that it sent correctly :/ On 19-Mar-13 03:04, Maxim Kuvyrkov wrote: Will commit to trunk once the server is up. Regarding 4.8, we should've really tried to work it out earlier. If you want to pursue backport to 4.8, please attach the log of PPA system rejecting the package The error is: == Finished at 20130318-0642 Build needed 00:14:20, 804796k disk space Function `__gthread_get_tsd_data' implicitly converted to pointer at /build/buildd/gcc-powerpc-wrs-vxworks-4.8.0+0svn196132/libgcc/config/vxlib-tls.c:164 Our automated build log filter detected the problem(s) above that will likely cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. This is often due to a missing function prototype definition. Since use of implicitly converted pointers is always fatal to the application on ia64, they are errors. Please correct them for your next upload. == This problem does not apply on the target (powerpc-wrs-vxworks), where sizeof(int*) == sizeof(int(*)()) == sizeof(int) == 4. However, the build system's filters are too stupid to realize this. Because the warning is spurious really the fact that the automated build system rejects the package is a bug on the build system's part. However, doing it the Right Way is so _easy_... (fwiw, I don't quite understand which launchpad you are referring to). I am referring to https://launchpad.net/ubuntu/+ppas Thanks for your help. Robert Mason
Re: [PING^5] PR 54805: __gthread_tsd* in vxlib-tls.c
On 16-Feb-13 23:21, Maxim Kuvyrkov wrote: On 14/02/2013, at 10:18 AM, rbmj wrote: Here's the updated, (trivial) patch. Thanks. I'll apply this once 4.8 branches and trunk is back into development mode. Since GCC 4.9 has branched now are you still willing to commit (maybe after the outage is over; I don't know the state of the svn server)? One of my friends has also commented that the warning that this fixes causes the launchpad PPA system to reject the package (based on the build log), so is it possible for this to apply in 4.8.1 also? I don't know how that process works, I assume I'd have to wait until after 4.8.0 officially releases. I understand that it's way too late for 4.8.0 (_trivial_ as the fix is) :( Suggested ChangeLog: [libgcc] Robert Mason * config/vxlib-tls.c: Add prototypes for __gthread_tsd*() Robert Mason
Re: [PING^5] PR 54805: __gthread_tsd* in vxlib-tls.c
On 18-Jan-13 20:35, Maxim Kuvyrkov wrote: On 19/01/2013, at 9:18 AM, rbmj wrote: -150,7 +158,7 @@ static __gthread_once_t tls_init_guard = need to read tls_keys.dtor[key] atomically. */ static void -tls_delete_hook (void *tcb ATTRIBUTE_UNUSED) +tls_delete_hook (void *tcb) Don't remove ATTRIBUTE_UNUSED. TCB was and will remain unused #ifdef __RTP__. And #ifndef __RTP__ ? No, simply leave that line as is. ATTRIBUTE_UNUSED tells the compiler that a variable can be unused, but not necessarily is unused. It's fine to have this attribute set on variables that are used under certain preprocessor configurations. Seems like I kept this email in drafts and never sent it out... Sorry about that. Here's the updated, (trivial) patch. -- Robert Mason diff a/libgcc/config/vxlib-tls.c b/libgcc/config/vxlib-tls.c --- a/libgcc/config/vxlib-tls.c +++ b/libgcc/config/vxlib-tls.c @@ -102,6 +102,14 @@ extern void __gthread_set_tls_data (void extern void __gthread_enter_tls_dtor_context (void); extern void __gthread_leave_tls_dtor_context (void); +#ifndef __RTP__ + +extern void *__gthread_get_tsd_data (WIND_TCB *tcb); +extern void __gthread_set_tsd_data (WIND_TCB *tcb, void *data); +extern void __gthread_enter_tsd_dtor_context (WIND_TCB *tcb); +extern void __gthread_leave_tsd_dtor_context (WIND_TCB *tcb); + +#endif /* __RTP__ */ /* This is a global structure which records all of the active keys. @@ -185,7 +193,7 @@ tls_delete_hook (void *tcb ATTRIBUTE_UNU #ifdef __RTP__ __gthread_leave_tls_dtor_context (); #else - __gthread_leave_tsd_dtor_context (); + __gthread_leave_tsd_dtor_context (tcb); #endif #ifdef __RTP__ -- 1.7.10.4
Re: [PING^5] PR 54805: __gthread_tsd* in vxlib-tls.c
On 17-Jan-13 20:18, Mike Stump wrote: You are now entered into the most ignored and most trivial gcc patch contest. You presently are behind the leader, but, if you can get another 10 pings in before approval, you can win! Good luck. Thanks. I know it's trivial, but 1. it's not hard to ping, and 2. for some reason small bugs just nag me :) On 17-Jan-13 21:15, Maxim Kuvyrkov wrote: Thanks for hanging out for so long. A couple of tips to increase your > luck with getting a patch reviewed. First, address your submission to > specific people, use your best-guess to choose a maintainer who can > review this patch. Otherwise diffusion of responsibility will kill > your patch (everyone will think that someone else will review it). Thanks, I'll keep that in mind. > Second -- present the full problem statement in the patch submission, > don't just reference a PR . To make a click we (reviewers and > maintainers) need to move our hand from keyboard to mouse, and that's > so hard when we are just scanning the mailing list. OK. It just seemed redundant to put the same information in both the bug tracker and the mailing list. Again, I'll remember to provide more info. Lastly, your patch is OK with the following nitpicks. I will check in > your [updated] patch once GCC 4.8 branches and trunk opens for > development. [Strictly, I'm not a maintainer, but this is a trivial > cleanup.] + +#endif /* __ RTP __ */ /* This is a global structure which records all of the active keys. @@ -150,7 +158,7 @@ static __gthread_once_t tls_init_guard = need to read tls_keys.dtor[key] atomically. */ static void -tls_delete_hook (void *tcb ATTRIBUTE_UNUSED) +tls_delete_hook (void *tcb) Don't remove ATTRIBUTE_UNUSED. TCB was and will remain unused #ifdef __RTP__. And #ifndef __RTP__ ? Thanks for looking! I'll make the necessary changes. -- Robert
Re: [PING^5] PR 54805: __gthread_tsd* in vxlib-tls.c
On 05-Jan-13 23:18, rbmj wrote: On 06-Dec-12 10:14, rbmj wrote: On 26-Nov-12 13:27, rbmj wrote: On 11/13/2012 10:22 PM, rbmj wrote: On 11/5/2012 12:57 PM, rbmj wrote: This removes warnings about implicit declarations and fixes one of the function calls in vxlib-tls.c for vxworks targets. I got the old prototypes from http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01314.html See bug for further details. Someone please comment or commit :) Ping: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00406.html Robert Mason Ping^2 Ping^3? Ping^4? Dare I ping^5?
Re: [PING^4] PR 54805: __gthread_tsd* in vxlib-tls.c
On 06-Dec-12 10:14, rbmj wrote: On 26-Nov-12 13:27, rbmj wrote: On 11/13/2012 10:22 PM, rbmj wrote: On 11/5/2012 12:57 PM, rbmj wrote: This removes warnings about implicit declarations and fixes one of the function calls in vxlib-tls.c for vxworks targets. I got the old prototypes from http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01314.html See bug for further details. Someone please comment or commit :) Ping: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00406.html Robert Mason Ping^2 Ping^3? Ping^4?
Re: [PING^2] PR 54805: __gthread_tsd* in vxlib-tls.c
On 26-Nov-12 13:27, rbmj wrote: On 11/13/2012 10:22 PM, rbmj wrote: On 11/5/2012 12:57 PM, rbmj wrote: This removes warnings about implicit declarations and fixes one of the function calls in vxlib-tls.c for vxworks targets. I got the old prototypes from http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01314.html See bug for further details. Someone please comment or commit :) Ping: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00406.html Robert Mason Ping^2 Ping^3?
[PING^2] PR 54805: __gthread_tsd* in vxlib-tls.c
On 11/13/2012 10:22 PM, rbmj wrote: On 11/5/2012 12:57 PM, rbmj wrote: This removes warnings about implicit declarations and fixes one of the function calls in vxlib-tls.c for vxworks targets. I got the old prototypes from http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01314.html See bug for further details. Someone please comment or commit :) Ping: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00406.html Robert Mason Ping^2
[PING] PR 54805: __gthread_tsd* in vxlib-tls.c
On 11/5/2012 12:57 PM, rbmj wrote: This removes warnings about implicit declarations and fixes one of the function calls in vxlib-tls.c for vxworks targets. I got the old prototypes from http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01314.html See bug for further details. Someone please comment or commit :) Ping: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00406.html Robert Mason
PR 54805: __gthread_tsd* in vxlib-tls.c
Hello all,
Since nobody has commented on bug 54805, and I'm pretty sure this is
valid (and obvious), I'm just submitting it to the list.
This removes warnings about implicit declarations and fixes one of the
function calls in vxlib-tls.c for vxworks targets.
I got the old prototypes from
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01314.html
See bug for further details.
Someone please comment or commit :)
--
Robert Mason
>From d008e235167796417cf6a8f68f7206dc4351b5c3 Mon Sep 17 00:00:00 2001
From: rbmj
Date: Wed, 26 Sep 2012 20:12:52 -0400
Subject: [PATCH] [libgcc] * config/vxlib-tls.c: Put declarations for
kernel space TSD
---
libgcc/config/vxlib-tls.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libgcc/config/vxlib-tls.c b/libgcc/config/vxlib-tls.c
index c469676..a2f5e34 100644
--- a/libgcc/config/vxlib-tls.c
+++ b/libgcc/config/vxlib-tls.c
@@ -102,6 +102,14 @@ extern void __gthread_set_tls_data (void
extern void __gthread_enter_tls_dtor_context (void);
extern void __gthread_leave_tls_dtor_context (void);
+#ifndef __RTP__
+
+extern void *__gthread_get_tsd_data(WIND_TCB *tcb);
+extern void __gthread_set_tsd_data(WIND_TCB *tcb, void *data);
+extern void __gthread_enter_tsd_dtor_context(WIND_TCB *tcb);
+extern void __gthread_leave_tsd_dtor_context(WIND_TCB *tcb);
+
+#endif /* __RTP__ */
/* This is a global structure which records all of the active keys.
@@ -150,7 +158,7 @@ static __gthread_once_t tls_init_guard =
need to read tls_keys.dtor[key] atomically. */
static void
-tls_delete_hook (void *tcb ATTRIBUTE_UNUSED)
+tls_delete_hook (void *tcb)
{
struct tls_data *data;
__gthread_key_t key;
@@ -185,7 +193,7 @@ tls_delete_hook (void *tcb ATTRIBUTE_UNU
#ifdef __RTP__
__gthread_leave_tls_dtor_context ();
#else
- __gthread_leave_tsd_dtor_context ();
+ __gthread_leave_tsd_dtor_context (tcb);
#endif
#ifdef __RTP__
-- 1.7.10.4
Re: Parts 3 and 4 to the vxworks/fixincludes patches
On 11/1/2012 10:48 AM, Bruce Korb wrote: Hi Robert, On Thu, Nov 1, 2012 at 6:35 AM, rbmj wrote: and now my patches will build on top of trunk. Bruce, can you give steps on how to reproduce the error you reported? rm -rf gcc-bld gcc-ins cp -l gcc-svn gcc-bld pfx=$PWD/gcc-ins cd gcc-bld ./configure --enable-languages=c,c++ --prefix=$pfx CFLAGS='-g2 -Wall' make I never build in my source tree. Doing (roughly) equivalent in git: gcc$ git reset --hard HEAD #clean stuff up gcc$ git clean -f -d # more cleaning gcc$ git checkout -b test # new branch at current HEAD gcc$ git am ../patches/* # applies my patches gcc$ cd ../build build$ ../gcc/configure --enable-languages=c,c++ --prefix=$pfx --disable-multilib CFLAGS='-g2 -Wall' #need to use disable-multilib or the whole thing dies... build$ make -j2 build$ make install I get no errors on a fresh fedora vm rev193071 I build using my vc tree as it's significantly quicker to tell git to make a new branch to build and then just throw that branch away than it is to copy my whole source tree. Are you sure that those three *minor* changes are what is breaking your build? -- rbmj
Re: Parts 3 and 4 to the vxworks/fixincludes patches
On 10/29/2012 10:07 PM, rbmj wrote: I get a clean build on my end... no stdarg.h issues. Build characteristics are given in the previous email. On 10/29/2012 4:26 PM, rbmj wrote: The build does eventually die in libstdc++-v3, but that's not due to these changes (it gives me an internal compiler error while compiling complex_io.cc inside of , see bug 55126) This is fixed by the patch in the comments of bug 54957. With this applied (along with a very minor gthread fix at 54805) I get a good build. This fix is applied in 193052, and now my patches will build on top of trunk. Bruce, can you give steps on how to reproduce the error you reported?
Re: Parts 3 and 4 to the vxworks/fixincludes patches
I get a clean build on my end... no stdarg.h issues. Build characteristics are given in the previous email. On 10/29/2012 4:26 PM, rbmj wrote: The build does eventually die in libstdc++-v3, but that's not due to these changes (it gives me an internal compiler error while compiling complex_io.cc inside of , see bug 55126) This is fixed by the patch in the comments of bug 54957. With this applied (along with a very minor gthread fix at 54805) I get a good build. Robert
Re: Parts 3 and 4 to the vxworks/fixincludes patches
On 10/29/2012 12:53 PM, Bruce Korb wrote: The first two patches I've applied. The remaining two are needed to fully enable building the VxWorks flavor of GCC, but those bits affect parts outside of fixincludes and there is some breakage somewhere. All evidence seems to me to show fixincludes still doing its thing correctly, but somewhere along the line the build becomes confused and unable to find stdarg.h: echo timestamp > stmp-int-hdrs g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables \ -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute \ -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common \ -DHAVE_CONFIG_H -I. -Ilto -I../.././gcc -I../.././gcc/lto -I../.././gcc/../include \ -I../.././gcc/../libcpp/include -I../.././gcc/../libdecnumber \ -I../.././gcc/../libdecnumber/bid -I../libdecnumber -I../.././gcc/../libbacktrace \ ../.././gcc/lto/lto-lang.c -o lto/lto-lang.o In file included from ../.././gcc/lto/lto-lang.c:22:0: ../.././gcc/system.h:28:20: fatal error: stdarg.h: No such file or directory #include ^ compilation terminated. Shouldn't stdarg.h be generated by GCC (IIRC)? Regardless, I can't reproduce the error. Compiling with these options: ../gcc/configure --prefix=/usr --target=powerpc-wrs-vxworks --with-gnu-as --with-gnu-ld --with-headers --disable-shared --disable-libssp --disable-multilib --with-float=hard --enable-languages=c,c++ --enable-libstdcxx --enable-threads=vxworks --without-gconv --disable-libgomp --disable-nls --disable-libmudflap --with-cpu-PPC603 --disable-symvers I use headers from: ftp://ftp.ni.com/pub/devzone/tut/updated_vxworks63gccdist.zip From this zip, I extract gccdist/WindRiver/vxworks-6.3/target/h/* into /usr/powerpc-wrs-vxworks/sys-include, and symlink /usr/powerpc-wrs-vxworks/include to sys-include/wrn/coreip GCC & libgcc compile fine. The build does eventually die in libstdc++-v3, but that's not due to these changes (it gives me an internal compiler error while compiling complex_io.cc inside of , see bug 55126) I have not been able to run down the cause. Until I've found it, I'm holding back on the bits that change stuff outside of fixincludes: gcc/gcov-io.c libstdc++-v3/config/os/vxworks/os_defines.h configure.ac I hope someone knows what this is. So do I.
Re: [PATCH] fix up fixincludes for VxWorks and fix testing
Forgot to attach...
On 10/2/2012 2:11 PM, rbmj wrote:
Patch 2: [fixincludes] Clean up fixincludes test machinery
TODO Prior to commit:
* fixincl.x: Regenerate
ChangeLog
2012-09-23 Bruce Korb
* check.tpl: export TEST_MODE=true for testing
* fixincl.c (te_verbose): extract to fixlib.h
(run_compiles): in test mode, if the fix is a replacement,
then skip the test. The fix will not be applied.
* fixlib.h (fixinc_mode): new global variable that defaults to
TESTING_OFF but is set to TESTING_ON when TEST_MODE is true.
* fixopts.c: define this global variable
(initialize_opts): set it to TESTING_ON under proper conditions
* inclhack.def (AAB_darwin7_9_long_double_funcs_2): this is *NOT*
a replacement fix. Rename it and move it where it belongs as
(darwin_9_long_double_funcs_2): renamed fix
(broken_nan): this had a broken selection regex. Could never work.
* tests/base/architecture/ppc/math.h: replacement fixes are not
tested,
so remove all the replacement text. Add in the "broken_nan" test
that used to never, ever fire.
>From 56861b9c45b43c1443f88e56e6fa46fde590a70f Mon Sep 17 00:00:00 2001
From: rbmj
Date: Tue, 2 Oct 2012 13:52:27 -0400
Subject: [PATCH 2/4] [fixincludes] Clean up fixincludes test machinery
---
fixincludes/README |3 +++
fixincludes/check.tpl|1 +
fixincludes/fixincl.c| 27 +++
fixincludes/fixlib.h | 26 +-
fixincludes/fixopts.c| 42 +++---
fixincludes/fixtests.c |2 +-
fixincludes/inclhack.def | 42 +-
fixincludes/tests/base/architecture/ppc/math.h | 84 +---
7 files changed, 89 insertions(+), 54 deletions(-)
diff --git a/fixincludes/README b/fixincludes/README
index c7144a0..9b48210 100644
--- a/fixincludes/README
+++ b/fixincludes/README
@@ -44,6 +44,9 @@ To make your fix, you will need to do several things:
Make sure it is now properly handled. Add tests to the
"test_text" entry(ies) that validate your fix. This will
help ensure that future fixes won't negate your work.
+Do *NOT* specify test text for "wrap" or "replacement" fixes.
+There is no real possibility that these fixes will fail.
+If they do, you will surely know straight away.
5. Go into the fixincludes build directory and type, "make check".
You are guaranteed to have issues printed out as a result.
diff --git a/fixincludes/check.tpl b/fixincludes/check.tpl
index a9810e2..0d1f444 100644
--- a/fixincludes/check.tpl
+++ b/fixincludes/check.tpl
@@ -99,6 +99,7 @@ ENDFOR fix
=]
+export TEST_MODE=true
find . -type f | sed 's;^\./;;' | sort | ../../fixincl
cd ${DESTDIR}
diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c
index 1133534..fecfb19 100644
--- a/fixincludes/fixincl.c
+++ b/fixincludes/fixincl.c
@@ -53,22 +53,8 @@ static const char z_std_preamble[] =
original, manufacturer supplied header file. */\n\n";
int find_base_len = 0;
-
-typedef enum {
- VERB_SILENT = 0,
- VERB_FIXES,
- VERB_APPLIES,
- VERB_PROGRESS,
- VERB_TESTS,
- VERB_EVERYTHING
-} te_verbose;
-
-te_verbose verbose_level = VERB_PROGRESS;
int have_tty = 0;
-#define VLEVEL(l) ((unsigned int) verbose_level >= (unsigned int) l)
-#define NOT_SILENT VLEVEL(VERB_FIXES)
-
pid_t process_chain_head = (pid_t) -1;
char* pz_curr_file; /* name of the current file under test/fix */
@@ -412,8 +398,17 @@ run_compiles (void)
/* FOR every fixup, ... */
do
{
- tTestDesc *p_test = p_fixd->p_test_desc;
- int test_ct = p_fixd->test_ct;
+ tTestDesc *p_test;
+ int test_ct;
+
+ if (fixinc_mode && (p_fixd->fd_flags & FD_REPLACEMENT))
+{
+ p_fixd->fd_flags |= FD_SKIP_TEST;
+ continue;
+}
+
+ p_test = p_fixd->p_test_desc;
+ test_ct = p_fixd->test_ct;
/* IF the machine type pointer is not NULL (we are not in test mode)
AND this test is for or not done on particular machines
diff --git a/fixincludes/fixlib.h b/fixincludes/fixlib.h
index 42d98b2..19df48a 100644
--- a/fixincludes/fixlib.h
+++ b/fixincludes/fixlib.h
@@ -140,7 +140,10 @@ typedef int apply_fix_p_t; /* Apply Fix Predicate Type */
"amount of user entertainment" )\
\
_ENV_( pz_find_base, BOOL_TRUE, "FIND_BASE", \
- "leader to trim from file names" )
+ "leader to trim from file names" ) \
+ \
+ _ENV_( pz_test_mode, BOOL_FALSE, "TEST_MODE", \
+ "run fixincludes in test mode" )
#define _ENV_(v,m,n,t) extern tCC* v;
ENV_TABLE
@@ -211,6 +214,27 @@ typ
Re: [PATCH] fix up fixincludes for VxWorks and fix testing
Patch 4: Minor changes to fix compilation on VxWorks
ChangeLog [gcc]:
* gcov-io.c (gcov_open): Pass third argument to open() unconditionally
ChangeLog [libstdc++-v3]:
* libstdc++-v3/config/os/vxworks/os_defines.h: Define NOMINMAX
>From 420bf6c2b0bde5f1689663b477add8fc9df2a6f0 Mon Sep 17 00:00:00 2001
From: rbmj
Date: Tue, 2 Oct 2012 13:55:02 -0400
Subject: [PATCH 4/4] Minor source changes to allow compilation on VxWorks
---
gcc/gcov-io.c |3 ++-
libstdc++-v3/config/os/vxworks/os_defines.h |6 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/gcc/gcov-io.c b/gcc/gcov-io.c
index d64fb42..f562654 100644
--- a/gcc/gcov-io.c
+++ b/gcc/gcov-io.c
@@ -92,7 +92,8 @@ gcov_open (const char *name, int mode)
{
/* Read-only mode - acquire a read-lock. */
s_flock.l_type = F_RDLCK;
- fd = open (name, O_RDONLY);
+ /* pass mode (ignored) for compatibility */
+ fd = open (name, O_RDONLY, S_IRUSR | S_IWUSR);
}
else
{
diff --git a/libstdc++-v3/config/os/vxworks/os_defines.h b/libstdc++-v3/config/os/vxworks/os_defines.h
index c66063e..93ad1d4 100644
--- a/libstdc++-v3/config/os/vxworks/os_defines.h
+++ b/libstdc++-v3/config/os/vxworks/os_defines.h
@@ -33,4 +33,10 @@
// System-specific #define, typedefs, corrections, etc, go here. This
// file will come before all others.
+//Keep vxWorks from defining min()/max() as macros
+#ifdef NOMINMAX
+#undef NOMINMAX
+#endif
+#define NOMINMAX 1
+
#endif
--
1.7.10.4
Re: [PATCH] fix up fixincludes for VxWorks and fix testing
Patch 3: Add --enable-libstdcxx option at top level configure
TODO prior to commit:
* configure: regenerate
ChangeLog:
* configure.ac: Add --enable-libstdcxx option
>From 3f0d38b7b7b70659a57ac4266701a71a5f948860 Mon Sep 17 00:00:00 2001
From: rbmj
Date: Tue, 2 Oct 2012 13:54:21 -0400
Subject: [PATCH 3/4] Add --enable-libstdcxx option at top level configure
---
configure.ac | 38 +-
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/configure.ac b/configure.ac
index f0d86d9..5325695 100644
--- a/configure.ac
+++ b/configure.ac
@@ -427,6 +427,15 @@ AC_ARG_ENABLE(libssp,
ENABLE_LIBSSP=$enableval,
ENABLE_LIBSSP=yes)
+AC_ARG_ENABLE(libstdcxx,
+AS_HELP_STRING([--disable-libstdcxx],
+ [do not build libstdc++-v3 directory]),
+ENABLE_LIBSTDCXX=$enableval,
+ENABLE_LIBSTDCXX=default)
+[if test "${ENABLE_LIBSTDCXX}" = "no" ; then
+ noconfigdirs="$noconfigdirs libstdc++-v3"
+fi]
+
# Save it here so that, even in case of --enable-libgcj, if the Java
# front-end isn't enabled, we still get libgcj disabled.
libgcj_saved=$libgcj
@@ -562,19 +571,22 @@ case "${target}" in
esac
# Disable libstdc++-v3 for some systems.
-case "${target}" in
- *-*-vxworks*)
-# VxWorks uses the Dinkumware C++ library.
-noconfigdirs="$noconfigdirs target-libstdc++-v3"
-;;
- arm*-wince-pe*)
-# the C++ libraries don't build on top of CE's C libraries
-noconfigdirs="$noconfigdirs target-libstdc++-v3"
-;;
- avr-*-*)
-noconfigdirs="$noconfigdirs target-libstdc++-v3"
-;;
-esac
+# Allow user to override this if they pass --enable-libstdc++-v3
+if test "${ENABLE_LIBSTDCXX}" = "default" ; then
+ case "${target}" in
+*-*-vxworks*)
+ # VxWorks uses the Dinkumware C++ library.
+ noconfigdirs="$noconfigdirs target-libstdc++-v3"
+ ;;
+arm*-wince-pe*)
+ # the C++ libraries don't build on top of CE's C libraries
+ noconfigdirs="$noconfigdirs target-libstdc++-v3"
+ ;;
+avr-*-*)
+ noconfigdirs="$noconfigdirs target-libstdc++-v3"
+ ;;
+ esac
+fi
# Disable Fortran for some systems.
case "${target}" in
--
1.7.10.4
Re: [PATCH] fix up fixincludes for VxWorks and fix testing
Patch 2: [fixincludes] Clean up fixincludes test machinery TODO Prior to commit: * fixincl.x: Regenerate ChangeLog 2012-09-23 Bruce Korb * check.tpl: export TEST_MODE=true for testing * fixincl.c (te_verbose): extract to fixlib.h (run_compiles): in test mode, if the fix is a replacement, then skip the test. The fix will not be applied. * fixlib.h (fixinc_mode): new global variable that defaults to TESTING_OFF but is set to TESTING_ON when TEST_MODE is true. * fixopts.c: define this global variable (initialize_opts): set it to TESTING_ON under proper conditions * inclhack.def (AAB_darwin7_9_long_double_funcs_2): this is *NOT* a replacement fix. Rename it and move it where it belongs as (darwin_9_long_double_funcs_2): renamed fix (broken_nan): this had a broken selection regex. Could never work. * tests/base/architecture/ppc/math.h: replacement fixes are not tested, so remove all the replacement text. Add in the "broken_nan" test that used to never, ever fire.
Re: [PATCH] fix up fixincludes for VxWorks and fix testing
Forgot to attach.
On 10/2/2012 2:09 PM, rbmj wrote:
Patch 1: [fixincludes] Fixes for VxWorks
TODO Prior to commit:
* fixincl.x: Regenerate
ChangeLog [fixincludes]:
2012-06-19 Robert Mason
* fixinc.in: Check to see if the machine_name fix needs to be
disabled.
viz. vxworks must not check the machine name for fix applicability.
* inclhack.def (AAB_vxworks_assert): New replacement fix
(AAB_vxworks_regs_vxtypes): likewise
(AAB_vxworks_stdint): and again
(AAB_vxworks_unistd) and yet again
(vxworks_ioctl_macro): wrap ioctl function in macro
(vxworks_mkdir_macro): remove mkdir() args vxworks doesn't support
(vxworks_regs): make sure regs.h comes from above arch directory.
(vxworks_write_const): add "const" attribute to data argument
* mkfixinc.sh: remove "vxworks" from list of platforms skipped by
fixincludes
2012-09-23 Bruce Korb
* tests/base/ioLib.h: new test header for new vxworks fix.
* tests/base/math.h: fix results movement
* tests/base/sys/stat.h: vxworks test
* tests/base/testing.h: vxworks test
>From 5da04a0758548288d5f004ed294ac3e903e229a8 Mon Sep 17 00:00:00 2001
From: rbmj
Date: Tue, 2 Oct 2012 13:51:18 -0400
Subject: [PATCH 1/4] [fixincludes] Add fixes for VxWorks
---
fixincludes/fixinc.in | 16 ++
fixincludes/inclhack.def | 266
fixincludes/mkfixinc.sh|1 -
fixincludes/tests/base/ioLib.h | 19 ++
fixincludes/tests/base/math.h | 10 +-
fixincludes/tests/base/sys/stat.h |7 +
fixincludes/tests/base/testing.h |6 +
8 files changed, 324 insertions(+), 85 deletions(-)
create mode 100644 fixincludes/tests/base/ioLib.h
diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in
index e73aed9..f7b8d8f 100755
--- a/fixincludes/fixinc.in
+++ b/fixincludes/fixinc.in
@@ -128,6 +128,22 @@ fi
# # # # # # # # # # # # # # # # # # # # #
#
+# Check to see if the machine_name fix needs to be disabled.
+#
+# On some platforms, machine_name doesn't work properly and
+# breaks some of the header files. Since everything works
+# properly without it, just wipe the macro list to
+# disable the fix.
+
+case "${target_canonical}" in
+*-*-vxworks*)
+ test -f ${MACRO_LIST} && echo > ${MACRO_LIST}
+;;
+esac
+
+
+# # # # # # # # # # # # # # # # # # # # #
+#
# In the file macro_list are listed all the predefined
# macros that are not in the C89 reserved namespace (the reserved
# namespace is all identifiers beginnning with two underscores or one
diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index 82792af..c5ae854 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -354,6 +354,206 @@ 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_;
+};
+
+/*
+ * Add needed include to regs.h (NOT the gcc header) on VxWorks
+ */
+
+fix = {
+hackname= AAB_vxworks_regs_vxtypes;
+files = regs.h;
+mach= "*-*-vxworks*";
+
+replace = <<- _EndOfHeader_
+ #ifndef _REGS_H
+ #define _REGS_H
+ #include
+ #include_next
+ #endif
+ _EndOfHeader_;
+};
+
+/*
+ * 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
+
+ /* get legacy vxworks types for compatibility */
+ #include
+
+ 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;
+ typed
Re: [PATCH] fix up fixincludes for VxWorks and fix testing
Patch 1: [fixincludes] Fixes for VxWorks TODO Prior to commit: * fixincl.x: Regenerate ChangeLog [fixincludes]: 2012-06-19 Robert Mason * fixinc.in: Check to see if the machine_name fix needs to be disabled. viz. vxworks must not check the machine name for fix applicability. * inclhack.def (AAB_vxworks_assert): New replacement fix (AAB_vxworks_regs_vxtypes): likewise (AAB_vxworks_stdint): and again (AAB_vxworks_unistd) and yet again (vxworks_ioctl_macro): wrap ioctl function in macro (vxworks_mkdir_macro): remove mkdir() args vxworks doesn't support (vxworks_regs): make sure regs.h comes from above arch directory. (vxworks_write_const): add "const" attribute to data argument * mkfixinc.sh: remove "vxworks" from list of platforms skipped by fixincludes 2012-09-23 Bruce Korb * tests/base/ioLib.h: new test header for new vxworks fix. * tests/base/math.h: fix results movement * tests/base/sys/stat.h: vxworks test * tests/base/testing.h: vxworks test
Re: [PATCH] fix up fixincludes for VxWorks and fix testing
On 9/23/2012 7:19 PM, Bruce Korb wrote: The attached patch needs to be split into two and I will do that before I actually push the thing. Since I have run out of play time this weekend and since I will be in the Ukraine in two weeks for two weeks, this patch is unlikely to get pushed before the end of October. Sorry about that. I've tried to do some of this work since Bruce is out. I ended up splitting it into four patches. Patches to follow, Robert Mason
[PING] Re: VxWorks Patches Back from the Dead!
Ping? Just did a full pull and rebuild today and everything still works :) Robert Mason On 9/10/2012 3:46 PM, Bruce Korb wrote: Hi, On Mon, Sep 10, 2012 at 10:48 AM, rbmj wrote: On the other hand, I've read this on the website: Don't mix together changes made for different reasons. Send them individually. Ideally, each change you send should be impossible to subdivide into parts that we might want to consider separately, because each of its parts gets its motivation from the other parts OTOH, this is a fairly cohesive set of patches. A single project. Even if, strictly speaking, each include fix is entirely separate from the others (by the design of fixincludes), I see them as a cohesive set that ought to be in a single commit. Fixes to fixes for fixincludes have been very infrequent. ... At the same time, it's a pain in the rear to worry about 12 different commits I'm into comforting one's derriere. Unless cosmic rays break everything again, that should be all. :) OK. I'll push it on your behalf once the other bits have been approved by their approvers. Cheers - Bruce
Re: VxWorks Patches Back from the Dead!
On 9/10/2012 9:35 AM, Bruce Korb wrote: On 09/09/12 08:54, rbmj wrote: Just because I *love* bothering everyone with emails... I don't mind, as long as you don't expect me to do anything until I'm certain you've stabilized the patch ;) I'm glad you rolled it up into one patch, because I was eventually going to ask you to do that. Thank you. I keep thinking everything is stable, but then something changes (bitrot? something elsewhere in GCC? I don't know) and I have to regroup. Sorry for changing everything 10 times - please bear with me. At this point, I've recompiled with different settings about 10 times and it hasn't broken itself yet. I've tried in a different VM and it works there too. So *hopefully* it should be good. On the other hand, I've read this on the website: Don't mix together changes made for different reasons. Send them individually. Ideally, each change you send should be impossible to subdivide into parts that we might want to consider separately, because each of its parts gets its motivation from the other parts "impossible to subdivide into parts" seems like one patch per fixincludes rule (am I looking at the wrong level of granularity here?). At the same time, it's a pain in the rear to worry about 12 different commits (especially when I'm making changes, I git rebase a TON). I'm also not sure about practicality of this approach in terms of the amount of work it creates on all ends. Unless cosmic rays break everything again, that should be all. Thanks, Robert Mason
Re: VxWorks Patches Back from the Dead!
Just because I *love* bothering everyone with emails... I've made a few changes and squashed everything into a single patch for ease of application. The commit message is inside the patch, but here's the suggested ChangeLog: configure.ac: add --enable-libstdcxx option configure: regenerate [gcc] gcov-io.c (gcov_open): Pass mode to open() unconditionally [fixincludes] fixinc.in: Added ability to skip machine_name inclhack.def (AAB_vxworks_assert): Added fix inclhack.def (AAB_vxworks_regs_vxtypes): Added fix inclhack.def (AAB_vxworks_stdint): Added fix inclhack.def (AAB_vxworks_unistd): Added fix inclhack.def (vxworks_ioctl_macro): Added fix inclhack.def (vxworks_mkdir_macro): Added fix inclhack.def (vxworks_regs): Added fix inclhack.def (vxworks_write_const): Added fix fixincl.x: Regenerate mkfixinc.sh: Removed vxworks from list of no-op fixinc targets [libstdc++-v3] config/os/vxworks/os_defines.h: #define'd NOMINMAX Thanks, Robert Mason >From 2ce175a3c94e6d544e27a8f936728fbec8f1f004 Mon Sep 17 00:00:00 2001 From: rbmj Date: Mon, 4 Jun 2012 13:18:10 -0400 Subject: [PATCH] Fix issues with VxWorks Targets Fix 1: 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. This patch just replaces the assert.h header with another one that will work. It preserves the same format, just changes the spacing. Fix 2: 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. This way, the most common use case of ioctl (with a const char * for the third argument) will compile in C++, where pointers must be explicitly casted to int. Fix 3: Added vxworks_mkdir_macro fix This adds a macro to POSIX-ify VxWorks' mkdir() function by including a macro that wraps the function and takes an (ignored, but still evaluated) mode argument. Fix 4: Add fix to prevent 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. Fix 5: Add stdint.h wrapper for VxWorks. Vxworks 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++. There was additional discussion of adding the necessary macros to get gcc to have built-in recognition of the types, but I could not get that to work. That is also non-essential to this patch, which is primarily to fix a bug caused by relying on types in stdint.h that vxworks does not define. Fix 6: 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. Fix 7: Add fix to make write() const correct on VxWorks VxWorks' write() takes its second argument as non-const, so 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. I believe that the prototype is non-const for backwards compatibility with old verisons of vxworks, but these versions are not supported by modern GCC, so causing potential bugs on those platforms is a non-issue. Modern vxworks will not modify the string passed to it, so just changing the prototype will work silently. Fix 8: Make open() call more compatible in gcc/gcov-io.c In gcc/gcov-io.c, the call to open() only has two arguments. This is fine, as long as the system open() is standards compliant. However, on at least one system (vxworks real time processes), open() is a non-variadic function, so the call fails. This adds a third argument passed unconditionally to open for compatibility with non-variadic open(). On systems with variadic open(), the extra argument should just be ignored anyway. There was talk of replacing this change with a fixincludes macro definition of open(), but this breaks libstdc++-v3. Fix 9: Added --enable-libstdcxx option. This patch allows the user to force enable/disable building of libstdc++-v3 with a --enable-libstdcxx option to be congruent with the other runtime library o
Re: VxWorks Patches Back from the Dead!
Hi all,
I have a new set of patches attached to this email. I've made a few
changes since last time, and a full build works (finally, again).
-The ioctl patch removes superfluous parens (thanks Paolo)
-The mkdir patch has a more precise (or uglier, depending on your point
of view :P) regex, and uses the variadic macro fix (thanks again Paolo)
-It adds another fixincludes patch for vxworks *NOT GCC* regs.h as it
doesn't include vxTypesOld.h, which it needs
-The patch that adds the AC_ARG_ENABLE option to explicitly
enable/disable libstdc++-v3 now has the argument changed from
--disable-libstdc++-v3 to --disable-libstdcxx, as I was having weird
issues and changing it seemed to work. If someone who has more
experience with this than me (so anyone) knows that this should not make
a difference than feel free to reject this change and I'll fall back to
the old version.
-The patch to allow machine_name to be skipped and enable fixincludes
for vxworks is now *much* simpler (thanks Bruce)
-There's a new patch to add NOMINMAX to
libstdc++-v3/config/os/vxworks/os_defines.h to keep vxworks headers from
defining min and max as macros.
Note that the open() patch is NOT changed as the suggested change does
not work when also compiling libstdc++-v3. Passing the third argument
explicitly won't break anything - it will just be ignored - and is the
only resolution that has worked so far.
They're also not in the same order as I was rebasing quite a bit to try
and keep history in sync.
Also, I'm hoping since this is the third (or fourth for some of these
patches) time submitting them, hopefully they can eventually make their
way in :D. Could someone please volunteer to commit once it is all
approved?
Thank you all for the work you do on GCC, and the help you've given me
to get my patches up to the standard!
Robert Mason
>From f1132398e72e73c549cb7f608a3a43c0f4801bc3 Mon Sep 17 00:00:00 2001
From: rbmj
Date: Mon, 4 Jun 2012 13:18:10 -0400
Subject: [PATCH 01/12] 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.
This patch just replaces the assert.h header with another one that
will work. It preserves the same format, just changes the spacing.
Proposed by Robert Mason:
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00385.html
Approved by Nathan Sidwell:
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00549.html
Approved by Bruce Korb: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00552.html
Changes:
[fixincludes]
inclhack.def (AAB_vxworks_assert): Added fix.
fixincl.x: Regenerate
---
fixincludes/inclhack.def | 40
1 file changed, 40 insertions(+)
diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index 82792af..a9d582d 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.10.4
>From 1220d34b665432ba238e1b58119576f66c015772 Mon Sep 17 00:00:00 2001
From: rbmj
Date: Mon, 4 Jun 2012 14:16:26 -0400
Subject: [PATCH 02/12] 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. This way, the most common use case
of ioctl (with a const char * for the third argument) w
Re: VxWorks Patches Back from the Dead!
On 8/23/2012 7:54 AM, Paolo Bonzini wrote: Il 23/08/2012 13:46, rbmj ha scritto: On 8/23/2012 4:24 AM, Paolo Bonzini wrote: Subject: [PATCH 10/10] Make open() call more compatible in gcc/gcov-io.c In gcc/gcov-io.c, the call to open() only has two arguments. This is fine, as long as the system open() is standards compliant. So you have to add another fixincludes hack, adding a macro indirection like the one you have for ioctl: #define open(a, b, ...) __open(a, b , ##__VA_ARGS__, 0660) #define __open(a, b, c, ...) (open)(a, b, c) Again, just not sure about variadic macro compatibility. If that will work for both c89 and c99 and c++, then that looks good to me. Yes, GCC has variadic macros as an extension in C89 mode too. You need to experiment a bit with -pedantic and/or -ansi and/or -std=c89, though. So the variadic macros work for compiling GCC itself. However, I run into problems when compiling libstdc++-v3. The problem is that basic_file.cc defines __basic_file::open(), and the macro is substituting for this as well. So AFAICT the original solution (just passing unconditionally) is necessary. I don't see any pitfalls associated with this - do we really care *that* much about passing one extra int? Though it looks weird, it's clearly not unprecedented (as you said, it's not the rule, but it has certainly been done in other places). I don't see a way to use a macro that will not break the declaration. Is there a way that a macro can work that I'm missing? -- rbmj
Re: VxWorks Patches Back from the Dead!
On 8/25/2012 11:35 PM, rbmj wrote:
On 8/24/2012 4:59 PM, Bruce Korb wrote:
Hi Robert,
If you are going to defer, then:
On Fri, Aug 24, 2012 at 1:20 PM, rbmj wrote:
diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in
index e73aed9..de7be35 100755
--- a/fixincludes/fixinc.in
+++ b/fixincludes/fixinc.in
@@ -128,6 +128,18 @@ fi
# # # # # # # # # # # # # # # # # # # # #
#
+# Check to see if the machine_name fix needs to be disabled.
+#
+
+case "${target_canonical}" in
+*-*-vxworks*)
+machine_name_override="OVERRIDE"
replace this line with:
test -f ${MACRO_LIST} && rm -f ${MACRO_LIST}
The remaining part of the patch to this file is not necessary.
I like it!
Done, and patch is attached.
OK. make install doesn't seem to like it as much as I do. It complains
because it tries to install macro_list and can't find it. Proposed
solutions:
1. Change line to read test -f ${MACRO_LIST} && echo > ${MACRO_LIST}
Advantages- easy, simple
Disadvantages- might cause an unnecessary run of the fix. A very, very
small potential compile time hit.
2. Change line to read test -f ${MACRO_LIST} && rm -f ${MACRO_LIST} &&
touch ${MACRO_LIST}
Advantages- Will not unnecessarily run machine_name. Saves 4 bytes of
disk usage over option 1 :D
Disadvantages- Looks rather hackish; something about it feels wrong
3. Make macro_list optional for installation
Disadvantages- more complex, and I don't really feel like going back
into the makefiles again. That's a scary place.
--
rbmj
Re: VxWorks Patches Back from the Dead!
On 8/24/2012 4:59 PM, Bruce Korb wrote:
Hi Robert,
If you are going to defer, then:
On Fri, Aug 24, 2012 at 1:20 PM, rbmj wrote:
diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in
index e73aed9..de7be35 100755
--- a/fixincludes/fixinc.in
+++ b/fixincludes/fixinc.in
@@ -128,6 +128,18 @@ fi
# # # # # # # # # # # # # # # # # # # # #
#
+# Check to see if the machine_name fix needs to be disabled.
+#
+
+case "${target_canonical}" in
+*-*-vxworks*)
+machine_name_override="OVERRIDE"
replace this line with:
test -f ${MACRO_LIST} && rm -f ${MACRO_LIST}
The remaining part of the patch to this file is not necessary.
I like it!
Done, and patch is attached.
--
Robert Mason
>From 7980875af4a4ebc5e57f80d7143c59baeba2e98e Mon Sep 17 00:00:00 2001
From: rbmj
Date: Fri, 24 Aug 2012 15:32:10 -0400
Subject: [PATCH] Add ability to skip the machine_name fixincludes fix.
This patch adds the ability to skip the machine_name fixincludes
fix in fixinc.in by deleting the macro list.
It also removes vxworks from the list of no-op fix platforms in
order to allow necessary include fixes to allow a successful
build of the latest GCC.
---
fixincludes/fixinc.in | 16
fixincludes/mkfixinc.sh |1 -
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in
index e73aed9..53d1b23 100755
--- a/fixincludes/fixinc.in
+++ b/fixincludes/fixinc.in
@@ -128,6 +128,22 @@ fi
# # # # # # # # # # # # # # # # # # # # #
#
+# Check to see if the machine_name fix needs to be disabled.
+#
+# On some platforms, machine_name doesn't work properly and
+# breaks some of the header files. Since everything works
+# properly without it, just delete the macro list to
+# disable the fix.
+
+case "${target_canonical}" in
+*-*-vxworks*)
+ test -f ${MACRO_LIST} && rm -f ${MACRO_LIST}
+;;
+esac
+
+
+# # # # # # # # # # # # # # # # # # # # #
+#
# In the file macro_list are listed all the predefined
# macros that are not in the C89 reserved namespace (the reserved
# namespace is all identifiers beginnning with two underscores or one
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* | \
--
1.7.10.4
Re: VxWorks Patches Back from the Dead!
I have two candidate patches. I've tested both and either can supersede
the original 0001-fixincludes-machine_name patch.
The first is the original proposed sed expression:
---
fixincludes/mkfixinc.sh |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fixincludes/mkfixinc.sh b/fixincludes/mkfixinc.sh
index 89e8ab7..a9f7c30 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* | \
@@ -26,6 +25,12 @@ case $machine in
(echo "#! /bin/sh" ; echo "exit 0" ) > ${target}
;;
+*-*-vxworks* )
+# Platforms for which the machine_name fix breaks things
+sed '/if test -s .{MACRO_LIST}/s/$/ \&\& false/' \
+ ${srcdir}/fixinc.in > ${target} || exit 1
+;;
+
*)
cat < ${srcdir}/fixinc.in > ${target} || exit 1
;;
--
The second is adding a target-dependent override to fixinc.in directly
(IMHO more complex, but also more complete):
---
fixincludes/fixinc.in | 14 +-
fixincludes/mkfixinc.sh |1 -
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in
index e73aed9..de7be35 100755
--- a/fixincludes/fixinc.in
+++ b/fixincludes/fixinc.in
@@ -128,6 +128,18 @@ fi
# # # # # # # # # # # # # # # # # # # # #
#
+# Check to see if the machine_name fix needs to be disabled.
+#
+
+case "${target_canonical}" in
+*-*-vxworks*)
+machine_name_override="OVERRIDE"
+;;
+esac
+
+
+# # # # # # # # # # # # # # # # # # # # #
+#
# In the file macro_list are listed all the predefined
# macros that are not in the C89 reserved namespace (the reserved
# namespace is all identifiers beginnning with two underscores or one
@@ -137,7 +149,7 @@ fi
# Note dependency on ASCII. \012 = newline.
# tr ' ' '\n' is, alas, not portable.
-if test -s ${MACRO_LIST}
+if test -s ${MACRO_LIST} && test -z "${machine_name_override}"
then
if test $VERBOSE -gt 0; then
echo "Forbidden identifiers: `tr '\012' ' ' < ${MACRO_LIST}`"
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* | \
--
Both work for me, so whichever one you like wins.
On 8/24/2012 3:48 PM, Bruce Korb wrote:
I will approve any reasonably simple solution. :)
Yes, my earlier solution wasn't quite the simplest. Driving the screw
with the proverbial golden hammer...
Thank you for doing this, by the way!
No problem. Thank you for the (significantly larger) amount of work
that you (both individual and collective) do :D
--
Robert Mason
Re: VxWorks Patches Back from the Dead!
On 8/22/2012 8:52 PM, Bruce Korb wrote:
However I think it might be simpler to tweak mkfixinc.sh to
sed '/if test -s .{MACRO_LIST}/s/$/ && false/' \
${srcdir}/fixinc.in > ${target}
for vxworks rather than all that configury rigmarole.
That would eliminate changes to gcc/configure.ac and gcc/Makefile.in.
OK. One question though: Why not just have a case statement inside
fixinc.in? Just running the script through sed seems like a kludgier
solution.
e.g.
case ${target_canonical} in
*-*-vxworks*)
# Disable the machine name fix as it breaks things
machine_name_override='OVERRIDE'
;;
esac
if test -s ${MACRO_LIST} && test -z "${machine_name_override}"
--
Robert Mason
Re: VxWorks Patches Back from the Dead!
In gcc/gcov-io.c, the call to open() only has two arguments. This is fine, as long as the system open() is standards compliant. So you have to add another fixincludes hack, adding a macro indirection like the one you have for ioctl: #define open(a, b, ...) __open(a, b , ##__VA_ARGS__, 0660) #define __open(a, b, c, ...) (open)(a, b, c) Also forgot to note: I've seen passing the extra argument unconditionally (even though it's for a read-only open) other places in GCC sources, so that seems to be accepted practice. -- Robert Mason
Re: VxWorks Patches Back from the Dead!
On 8/23/2012 4:24 AM, Paolo Bonzini wrote: Some comments on the patches: + c_fix_arg = "%0\n" + "#define ioctl(fd, func, arg) ((ioctl)((fd), (func), ((int)(arg\n"; This can be simply #define ioctl(fd, func, arg) ioctl(fd, func, (int)arg) thanks to C and cpp precedence rules. OK. I just over-parenthesize all function-macros by default because I can never remember the rules exactly and worry about not anticipating what someone puts in a macro. + c_fix_arg = "%0\n" + "#ifdef IN_GCC\n" + "#define mkdir(dir, mode) ((mode), (mkdir)(dir))\n" + "#endif\n"; Are you sure about the #ifdef/#endif? In fact, you definitely do not want a _global_ include to have a dependency on a user symbol. The idea is I don't want to break existing code, so I only want this macro to take effect inside of GCC proper, as (AFAIK) anything built with the new compiler gets the fixed includes, and there's lots of VxWorks code that relies on single-argument mkdir. The alternative is varaidic macros, but I'm no expert on the nuances of c89 vs c99 variadic macros. Add fix to make write() const correct on VxWorks VxWorks' write() takes its second argument as non-const, so the compiler complains if one tries to pass a const pointer to it. I think this does not need to be VxWorks-specific, but I'm not sure of the standards for fixincludes. Bruce? I set it to only vxworks for now as that's the only platform that I 1. know has the issue and 2. know that it's safe to do this change. Subject: [PATCH 10/10] Make open() call more compatible in gcc/gcov-io.c In gcc/gcov-io.c, the call to open() only has two arguments. This is fine, as long as the system open() is standards compliant. So you have to add another fixincludes hack, adding a macro indirection like the one you have for ioctl: #define open(a, b, ...) __open(a, b , ##__VA_ARGS__, 0660) #define __open(a, b, c, ...) (open)(a, b, c) Again, just not sure about variadic macro compatibility. If that will work for both c89 and c99 and c++, then that looks good to me. -- Robert Mason
Re: VxWorks Patches Back from the Dead!
On 8/22/2012 8:52 PM, Bruce Korb wrote:
On 08/22/12 17:05, rbmj wrote:
Hello Everyone,
I have ten patches which are approved or obvious but waiting on commit
The include fixing stuff looks fine to me.
However I think it might be simpler to tweak mkfixinc.sh to
sed '/if test -s .{MACRO_LIST}/s/$/ && false/' \
${srcdir}/fixinc.in > ${target}
for vxworks rather than all that configury rigmarole.
That would eliminate changes to gcc/configure.ac and gcc/Makefile.in.
I didn't even think of that. I was probably doing all my fixes in the
Makefile because that was where I was looking with the original
problem. However, I'm looking at the result of that sed command, and I
don't think that the && is going to work, as when I run that sed command
I just get whitespace there. IIRC, sed handles '&' differently so it
probably needs to be escaped. I'll see if I get a chance to test that
later on.
Basically degrading the entire first patch to this:
$ svn diff mkfixinc.sh
Index: mkfixinc.sh
===
1 == '-u'
2 == '-L'
3 == 'mkfixinc.sh(revision 190448)'
4 == '-L'
5 == 'mkfixinc.sh(working copy)'
6 == '.svn/text-base/mkfixinc.sh.svn-base'
7 == 'mkfixinc.sh'
--- mkfixinc.sh(revision 190448)
+++ mkfixinc.sh(working copy)
@@ -15,7 +15,6 @@
i?86-*-mingw32* | \
x86_64-*-mingw32* | \
i?86-*-interix* | \
-*-*-vxworks* | \
powerpc-*-eabisim* | \
powerpc-*-eabi*| \
powerpc-*-rtems* | \
@@ -26,6 +25,11 @@
(echo "#! /bin/sh" ; echo "exit 0" ) > ${target}
;;
+*-*-vxworks* )
+sed '/if test -s .{MACRO_LIST}/s/$/ && false/' \
+${srcdir}/fixinc.in > ${target}
+;;
+
*)
cat < ${srcdir}/fixinc.in > ${target} || exit 1
;;
Assuming that when I test everything works and I can get a successful
build that works for me. Probably won't get a chance to test as I don't
have very much time until the weekend and right now there's another
regression in rs6000 (issue with one of the macros) that's breaking that
I have to fix before I get to that part of the build process.
Thanks for your input. That's certainly a simpler fix.
--
Robert Mason
VxWorks Patches Back from the Dead!
Hello Everyone,
I have ten patches which are approved or obvious but waiting on commit,
each of which is attached to this email. Feel free to consider this a
ping, HOWEVER, they are rebased onto the latest trunk so they're no
longer stale. Additionally, I updated the commit messages and with
complete proposed changelog entries. They all (inside the patch file)
have a link to their approval message and the original proposal message.
Note that ANY patch that touches fixincludes has a dependency on the
first patch (0001...), as fixincludes WILL NOT RUN without this patch on
a vxworks platform.
Sorry for the long latency period but I did not have access to a
computer for a substantial period of time over the summer. I've just
been able to get everything back up and running.
--
Robert Mason
>From 991c277c1be41dff96b474a1e8bb9d297042ac70 Mon Sep 17 00:00:00 2001
From: rbmj
Date: Wed, 30 May 2012 08:16:57 -0400
Subject: [PATCH 01/10] 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.
It also removes vxworks from the list of no-op fix platforms so that
fixincludes will run on that platform (it needs it).
Proposed by Robert Mason:
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00383.html
Approved by Nathan Sidwell:
http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00549.html
Approved by Bruce Korb: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00552.html
Changes:
[gcc]
configure.ac: Add target-based selection of new exported
variable skip_machine_name_fix
configure: Regenerate
Makefile.in: add check for SKIP_MACHINE_NAME_FIX
[fixincludes]
mkfixinc.sh: Remove vxworks from the list of no-op
fixincludes platforms as it needs some fixes
---
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 dddffb6..31b36eb 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -237,6 +237,9 @@ LINKER = $(CC)
LINKER_FLAGS = $(CFLAGS)
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
# ---
@@ -4045,10 +4048,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 7042c91..f5ff61c 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -5121,6 +5121,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.10.4
>From 5dd13cf6ae3cc76df8e51cbabf9ac6d7a879b880 Mon Sep 17 00:00:00 2001
From: rbmj
Date: Mon, 4 Jun 2012 13:18:10 -0400
Subject: [PATCH 02/10] 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
Re: [PATCH 3/7] Add stdint.h wrapper for VxWorks.
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.
On 06/21/2012 02:27 AM, Mike Stump wrote:
On Jun 20, 2012, at 12:36 PM, rbmj 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
>From 534222784011172403801a1617d67dba174c8441 Mon Sep 17 00:00:00 2001
From: rbmj
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: [Ping] Fix gcc/gcov.c and libgcc/libgcov.c to fix build on VxWorks
On 06/22/2012 06:52 PM, rbmj wrote:
On 06/11/2012 08:01 AM, Paolo Bonzini wrote:
Il 11/06/2012 13:56, rbmj ha scritto:
1. VxWorks does not have a variadic open - it must receive three
arguments. gcc/gcov.c however opens a file for reading and does not
pass in a mode argument, which causes an error on vxWorks. This just
adds a platform-based ifdef around this. I am aware that this is
against coding conventions, and if that is an issue, I can think of
two resolutions. [...] simply pass the extra mode argument in
unconditionally,
as it should be transparent to the function and ignored if it is
variadic (I'm no expert on calling conventions though).
Yes, please do this.
OK, I've prepared a patch. I would venture to say it is obvious.
I'll mock up a separate patch that resolves the mkdir() issue.
OK, so in addition to that small change, here's a fixincludes rule to
resolve the mkdir() issue, which I've tested and works correctly. It
depends on my patch [1] to allow fixincludes to run on VxWorks (note
that gcc/configure needs to be regened for that patch), and (as a
fixincludes rule patch) needs fixincl.x to be regened with
fixincludes/genfixes. Patch is attached.
This patch, together with the patch in my previous mail [2], resolves
bug 53264.
Thanks,
Robert Mason
[1] http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00383.html
[2] http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01508.html
>From 0e14c471820d4a44b372e4e1c9248b39f65e23c4 Mon Sep 17 00:00:00 2001
From: rbmj
Date: Sat, 23 Jun 2012 17:38:41 -0400
Subject: [PATCH] Added vxworks_mkdir_macro fix.
This adds a macro to POSIX-ify VxWorks' mkdir() function by
including a macro that wraps the function and takes an (ignored,
but still evaluated) mode argument.
Modified:
*fixincludes/inclhack.def (vxworks_mkdir_macro): add hack
*fixincludes/fixincl.x: Regenerate
---
fixincludes/inclhack.def | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index d122b6d..95b6607 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -4488,6 +4488,27 @@ fix = {
test_text = "extern int ioctl ( int asdf1234, int jkl , int qwerty ) ;";
};
+/*
+ * Wrap VxWorks mkdir to be posix compliant
+ */
+fix = {
+ hackname = vxworks_mkdir_macro;
+ files = sys/stat.h;
+ mach = "*-*-vxworks*";
+
+ c_fix = format;
+ c_fix_arg = "%0\n"
+ "#ifdef IN_GCC\n"
+ "#define mkdir(dir, mode) ((mode), (mkdir)(dir))\n"
+ "#endif\n";
+ c_fix_arg = "extern[\t ]+STATUS[\t ]+mkdir[\t ]*"
+"\\([\t ]*const[\t ]+char[\t ]*\\*[\t ]*" /* arg type */
+"(|[_[:alpha:]][_[:alnum:]]*)" /* arg name (optional) */
+"\\)[\t ]*;";
+
+ test_text = "extern STATUS mkdir (const char * _qwerty) ;";
+};
+
/*
* Fix VxWorks to not require including .
--
1.7.5.4
Re: [Ping] Fix gcc/gcov.c and libgcc/libgcov.c to fix build on VxWorks
On 06/11/2012 08:01 AM, Paolo Bonzini wrote:
Il 11/06/2012 13:56, rbmj ha scritto:
1. VxWorks does not have a variadic open - it must receive three
arguments. gcc/gcov.c however opens a file for reading and does not
pass in a mode argument, which causes an error on vxWorks. This just
adds a platform-based ifdef around this. I am aware that this is
against coding conventions, and if that is an issue, I can think of
two resolutions. [...] simply pass the extra mode argument in unconditionally,
as it should be transparent to the function and ignored if it is
variadic (I'm no expert on calling conventions though).
Yes, please do this.
OK, I've prepared a patch. I would venture to say it is obvious. I'll
mock up a separate patch that resolves the mkdir() issue.
Robert Mason
Changes:
gcc/gcov-io.c: pass mode argument unconditionally to be
compatible with non-variadic open() (e.g. on VxWorks).
---
gcc/gcov-io.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gcc/gcov-io.c b/gcc/gcov-io.c
index 37c1c3e..28ed52f 100644
--- a/gcc/gcov-io.c
+++ b/gcc/gcov-io.c
@@ -92,7 +92,8 @@ gcov_open (const char *name, int mode)
{
/* Read-only mode - acquire a read-lock. */
s_flock.l_type = F_RDLCK;
- fd = open (name, O_RDONLY);
+ /* pass mode (ignored) for compatibility */
+ fd = open (name, O_RDONLY, S_IRUSR | S_IWUSR);
}
else
{
--
1.7.5.4
Re: [Ping] Fix gcc/gcov.c and libgcc/libgcov.c to fix build on VxWorks
On 06/21/2012 09:40 PM, Hans-Peter Nilsson wrote: On Wed, 20 Jun 2012, rbmj wrote: There is an alternate solution- I could use fixincludes to add a macro to wrap over mkdir on VxWorks. A couple of possible ways to do this: 1. Define a normal macro to posix-ify it, i.e. #define mkdir(a, b) ((mkdir)(a)). Since this would hide single-argument mkdir, it would probably be best to wrap it in #ifdef IN_GCC in order to avoid breaking existing vxWorks code. Beware, if you go this route, I think you need to evaluate the "mode" argument (b above), i.e. something like "#define mkdir(a, b) ((b), (mkdir) (a))". Yes, you're correct. I think then that this makes the normal macro a better option than the variadic macro, even though the variadic is more compatible. Wrapping the mkdir macro in IN_GCC should provide an adequate guard to prevent the macro from expanding in code that relies on the non-compliant signature. I would ask who in the world puts expressions with side effects in as the mode argument and then relies on those side effects for something other than the (ignored) mode, but I know better :-P. I think this is better than the previous solution as it doesn't require touching GCC itself per-se, and instead deals with header incompatibilities where they should be dealt with in fixincludes. I'll write up a patch and put that with the other fixincludes patches I've submitted. Thanks, Robert
PING: [Patch] Add AC_ARG_ENABLE for libstdc++-v3
On 06/11/2012 03:05 PM, rbmj wrote: On 06/11/2012 08:02 AM, Paolo Bonzini wrote: Il 11/06/2012 13:59, rbmj ha scritto: On 05/22/2012 04:37 PM, rbmj wrote: This patch adds an AC_ARG_ENABLE option to build/not build libstdc++-v3. I wrote the patch in order to allow the user to override the automatic disable for libstdc++-v3 for certain targets. Ping^2 on http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01525.html Ok. If it's OK, could somebody please commit? Ping^3 - It's approved, but I don't have commit access, so could somebody please commit this for me? It should be trivial, just apply the patch and run autoconf2.64 in top-level. Thanks, Robert Mason
Re: [Ping] Fix gcc/gcov.c and libgcc/libgcov.c to fix build on VxWorks
On 06/12/2012 08:16 AM, rbmj wrote: On 06/11/2012 08:01 AM, Paolo Bonzini wrote: VxWorks should define TARGET_POSIX_IO if it has both access and mkdir. Please add it to gcc/config/vxworks.h if this is the case. I misspoke in my earlier email - sorry for my lack of attention to detail. The issue is that VxWorks does *not* have a two argument mkdir(). It does have TARGET_POSIX_IO. Undefing TARGET_POSIX_IO seems non-optimal as it disables some functionality that can still be implemented, just omitting the mode argument. With this in mind, I defined MKDIR_SINGLE_ARG in gcc/config/vxworks.h, and then added a check for this define. This is a slightly less ugly solution than I had earlier. An updated patch is attached. It's in git format-patch format, so the commit message is at the top. There is an alternate solution- I could use fixincludes to add a macro to wrap over mkdir on VxWorks. A couple of possible ways to do this: 1. Define a normal macro to posix-ify it, i.e. #define mkdir(a, b) ((mkdir)(a)). Since this would hide single-argument mkdir, it would probably be best to wrap it in #ifdef IN_GCC in order to avoid breaking existing vxWorks code. 2. Make a variadic macro to allow for posix compatibility, i.e. #define mkdir(a, ...) ((mkdir)(a)). I'm not sure if this works outside of C99 mode - I know GCC supports it as an extension in C89 mode, but AFAIK the semantics are slightly different. I'm also not sure about g++. This does have the advantage though that it doesn't break any existing code. However, it does allow nonsensical 20 argument mkdir as well. Either of these or the one in my previous email should work. Which (or a different one entirely) would be preferred? Thanks, Robert
Re: [PATCH 3/7] Add stdint.h wrapper for VxWorks.
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: typedefsigned charINT8; typedefsigned shortINT16; typedefsigned intINT32; typedefsigned long long INT64; typedefunsigned charUINT8; typedefunsigned shortUINT16; typedefunsigned intUINT32; typedefunsigned 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.
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/msg0.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.
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: [Ping] Fix gcc/gcov.c and libgcc/libgcov.c to fix build on VxWorks
On 06/11/2012 08:01 AM, Paolo Bonzini wrote:
Il 11/06/2012 13:56, rbmj ha scritto:
... simply pass the extra mode argument in unconditionally,
as it should be transparent to the function and ignored if it is
variadic (I'm no expert on calling conventions though).
Yes, please do this.
Done.
VxWorks should define TARGET_POSIX_IO if it has both access and mkdir.
Please add it to gcc/config/vxworks.h if this is the case.
I misspoke in my earlier email - sorry for my lack of attention to
detail. The issue is that
VxWorks does *not* have a two argument mkdir(). It does have
TARGET_POSIX_IO. Undefing TARGET_POSIX_IO seems non-optimal as it
disables some functionality that can still be implemented, just omitting
the mode argument. With this in mind, I defined MKDIR_SINGLE_ARG in
gcc/config/vxworks.h, and then added a check for this define. This is a
slightly less ugly solution than I had earlier.
An updated patch is attached. It's in git format-patch format, so the
commit message is at the top.
Robert
>From 61de9bcf6c0dc60185a84b07e0f8ad2f870b6799 Mon Sep 17 00:00:00 2001
From: rbmj
Date: Tue, 12 Jun 2012 07:54:20 -0400
Subject: [PATCH] Fixed compilation on VxWorks because of open()/mkdir()
VxWorks only has a single arg mkdir(), and kernel modules
only have a (fixed) three argument open() instead of the
compliant variadic version. For open(), pass the mode
argument unconditionally so that we always use three
arguments. This shouldn't break other platforms, as it will
just be ignored. For mkdir(), added MKDIR_SINGLE_ARG
(similarly to TARGET_POSIX_IO) in order to only use one
argument to maintain compatibility.
Modified:
*gcc/config/vxworks.h: Added define for MKDIR_SINGLE_ARG
*gcc/gcov-io.c (gcov_open): Pass in mode to open()
unconditionally to support non-variadic open()
*libgcc/libgcov.c (create_file_directory): Add check for
MKDIR_SINGLE_ARG to support single-argument mkdir()
---
gcc/config/vxworks.h |2 ++
gcc/gcov-io.c|2 +-
libgcc/libgcov.c |2 +-
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/config/vxworks.h b/gcc/config/vxworks.h
index 000de36..cd57f1a 100644
--- a/gcc/config/vxworks.h
+++ b/gcc/config/vxworks.h
@@ -117,6 +117,8 @@ extern void vxworks_asm_out_destructor (rtx symbol, int priority);
/* Both kernels and RTPs have the facilities required by this macro. */
#define TARGET_POSIX_IO
+#define MKDIR_SINGLE_ARG
+
/* A VxWorks implementation of TARGET_OS_CPP_BUILTINS. */
#define VXWORKS_OS_CPP_BUILTINS() \
diff --git a/gcc/gcov-io.c b/gcc/gcov-io.c
index 37c1c3e..13c1aa8 100644
--- a/gcc/gcov-io.c
+++ b/gcc/gcov-io.c
@@ -92,7 +92,7 @@ gcov_open (const char *name, int mode)
{
/* Read-only mode - acquire a read-lock. */
s_flock.l_type = F_RDLCK;
- fd = open (name, O_RDONLY);
+ fd = open (name, O_RDONLY, S_IRUSR | S_IWUSR);
}
else
{
diff --git a/libgcc/libgcov.c b/libgcc/libgcov.c
index 8ed8971..5c4fa1c 100644
--- a/libgcc/libgcov.c
+++ b/libgcc/libgcov.c
@@ -133,7 +133,7 @@ create_file_directory (char *filename)
/* Try to make directory if it doesn't already exist. */
if (access (filename, F_OK) == -1
-#ifdef TARGET_POSIX_IO
+#if defined(TARGET_POSIX_IO) && !defined(MKDIR_SINGLE_ARG)
&& mkdir (filename, 0755) == -1
#else
&& mkdir (filename) == -1
--
1.7.5.4
Re: [Patch] Add AC_ARG_ENABLE for libstdc++-v3
On 06/11/2012 08:02 AM, Paolo Bonzini wrote: Il 11/06/2012 13:59, rbmj ha scritto: On 05/22/2012 04:37 PM, rbmj wrote: This patch adds an AC_ARG_ENABLE option to build/not build libstdc++-v3. I wrote the patch in order to allow the user to override the automatic disable for libstdc++-v3 for certain targets. Ping^2 on http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01525.html Ok. If it's OK, could somebody please commit? Thanks, Robert
Re: [PATCH] Fixincludes/VxWorks
On 06/10/2012 02:38 PM, Bruce Korb wrote: On Sun, Jun 10, 2012 at 10:57 AM, Nathan Sidwell 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] Add AC_ARG_ENABLE for libstdc++-v3
On 05/22/2012 04:37 PM, rbmj wrote: This patch adds an AC_ARG_ENABLE option to build/not build libstdc++-v3. I wrote the patch in order to allow the user to override the automatic disable for libstdc++-v3 for certain targets. Ping^2 on http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01525.html Robert Mason
[Ping] Fix gcc/gcov.c and libgcc/libgcov.c to fix build on VxWorks
Hi everyone, Ping RE: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00086.html Thanks, Robert Mason On 06/01/2012 02:43 PM, rbmj wrote: On 06/01/2012 02:40 PM, rbmj wrote: Hi everyone, These fixes are to allow building on vxWorks. Currently there are two issues: 1. VxWorks does not have a variadic open - it must receive three arguments. gcc/gcov.c however opens a file for reading and does not pass in a mode argument, which causes an error on vxWorks. This just adds a platform-based ifdef around this. I am aware that this is against coding conventions, and if that is an issue, I can think of two resolutions. One, an autoconf macro to check for a non-variadic open, or two, simply pass the extra mode argument in unconditionally, as it should be transparent to the function and ignored if it is variadic (I'm no expert on calling conventions though). 2. VxWorks has a two argument mkdir(). libgcc/libgcov.c uses mkdir() and calls it with two arguments if TARGET_POSIX_IO is defined and only one argument otherwise. I don't know what TARGET_POSIX_IO is, but if it's anything more than just mkdir(), this is probably correct, as vxworks is only partially POSIX compliant. Again, another platform-based ifdef, so if that is anathema, it can be replaced by more autoconf hackery. The patch as-is compiles targeting on vxworks and bootstraps on a native x86_64-linux-gnu build (which makes sense, since it doesn't touch anything for non-vxworks). Gerald Pfeifer has volunteered to apply the patch if approved. Also, in an earlier message [1] Janne Blomqvist mentioned that newer versions of VxWorks do have the variadic open(), and this is true. However, as far as I know, this version is still not available for kernel modules, only real-time processes. Thanks, Robert Mason Sorry, forgot to add in the link. [1]: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01102.html
Re: [PATCH] Fixincludes/VxWorks
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.
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
[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(-)
>From e30ed6b06659f1d88fc76ea6fe83408bc6d3060c Mon Sep 17 00:00:00 2001
From: rbmj
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
[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(-)
>From 3a52d77fdbf4c422a1e641402794ce8eda47f410 Mon Sep 17 00:00:00 2001
From: rbmj
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 to not require including .
--
1.7.5.4
[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(-)
>From 2aa0effcb0e5b617e099a8390ce97677ba27a49a Mon Sep 17 00:00:00 2001
From: rbmj
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 ";
};
+/*
+ * Make it so VxWorks does not include gcc/regs.h accidentally
+ */
+fix = {
+ hackname = vxworks_regs;
+ mach = "*-*-vxworks*";
+
+ select = "#[\t ]*include[\t ]+";
+ c_fix = format;
+ c_fix_arg = "#include ";
+
+ test_text = "#include \n";
+};
+
/*
* Another bad dependency in VxWorks 5.2 .
--
1.7.5.4
[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(-)
>From e389d506193e80713b9511713a220867159f5a8e Mon Sep 17 00:00:00 2001
From: rbmj
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
+ #include
+ #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.
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(-)
>From a50ecd253f6e7fa4a6558ebce0578c5f48ccbc17 Mon Sep 17 00:00:00 2001
From: rbmj
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
+
+ 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 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(-)
>From d2cbe2a8f546abf5713e8a6ed614ef2eac1f749b Mon Sep 17 00:00:00 2001
From: rbmj
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 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(-)
>From 76bc7ef3c6a21502dd7af5b4427080b2cdd3cdd9 Mon Sep 17 00:00:00 2001
From: rbmj
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] Fixincludes/VxWorks
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: Ping - Re: [Patch] Add AC_ARG_ENABLE for libstdc++-v3
On 06/04/2012 04:32 PM, Paolo Carlini wrote: Remember that all the libstdc++-v3 patches should also go to libstd...@gcc.gnu.org. This isn't really a libstdc++ patch - it's actually a patch against top-level configure.ac that doesn't touch the libstdc++-v3 subdirectory. But if I should still cross post it, I can. I'm just not sure whether it counts as a "libstdc++-v3 patch". Robert Mason
Ping - Re: [Patch] Add AC_ARG_ENABLE for libstdc++-v3
On 05/22/2012 04:37 PM, rbmj wrote: This patch adds an AC_ARG_ENABLE option to build/not build libstdc++-v3. I wrote the patch in order to allow the user to override the automatic disable for libstdc++-v3 for certain targets. Hi all, What are the barriers to getting this in? I wrote this so I don't have to continuously patch the configure script, and instead can override it with a command line option for my build targeting powerpc-wrs-vxworks. Even though VxWorks has it's own libstdc++, that doesn't mean that one wouldn't want to build it in order to get a more recent version than stock. If it needs to be documented if someone can point me to the proper spot I can do that as well. Thanks, Robert Mason
Re: Fix gcc/gcov.c and libgcc/libgcov.c to fix build on VxWorks
On 06/01/2012 02:40 PM, rbmj wrote: Hi everyone, These fixes are to allow building on vxWorks. Currently there are two issues: 1. VxWorks does not have a variadic open - it must receive three arguments. gcc/gcov.c however opens a file for reading and does not pass in a mode argument, which causes an error on vxWorks. This just adds a platform-based ifdef around this. I am aware that this is against coding conventions, and if that is an issue, I can think of two resolutions. One, an autoconf macro to check for a non-variadic open, or two, simply pass the extra mode argument in unconditionally, as it should be transparent to the function and ignored if it is variadic (I'm no expert on calling conventions though). 2. VxWorks has a two argument mkdir(). libgcc/libgcov.c uses mkdir() and calls it with two arguments if TARGET_POSIX_IO is defined and only one argument otherwise. I don't know what TARGET_POSIX_IO is, but if it's anything more than just mkdir(), this is probably correct, as vxworks is only partially POSIX compliant. Again, another platform-based ifdef, so if that is anathema, it can be replaced by more autoconf hackery. The patch as-is compiles targeting on vxworks and bootstraps on a native x86_64-linux-gnu build (which makes sense, since it doesn't touch anything for non-vxworks). Gerald Pfeifer has volunteered to apply the patch if approved. Also, in an earlier message [1] Janne Blomqvist mentioned that newer versions of VxWorks do have the variadic open(), and this is true. However, as far as I know, this version is still not available for kernel modules, only real-time processes. Thanks, Robert Mason Sorry, forgot to add in the link. [1]: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01102.html
Fix gcc/gcov.c and libgcc/libgcov.c to fix build on VxWorks
Hi everyone,
These fixes are to allow building on vxWorks. Currently there are two
issues:
1. VxWorks does not have a variadic open - it must receive three
arguments. gcc/gcov.c however opens a file for reading and does not
pass in a mode argument, which causes an error on vxWorks. This just
adds a platform-based ifdef around this. I am aware that this is
against coding conventions, and if that is an issue, I can think of two
resolutions. One, an autoconf macro to check for a non-variadic open,
or two, simply pass the extra mode argument in unconditionally, as it
should be transparent to the function and ignored if it is variadic (I'm
no expert on calling conventions though).
2. VxWorks has a two argument mkdir(). libgcc/libgcov.c uses mkdir()
and calls it with two arguments if TARGET_POSIX_IO is defined and only
one argument otherwise. I don't know what TARGET_POSIX_IO is, but if
it's anything more than just mkdir(), this is probably correct, as
vxworks is only partially POSIX compliant. Again, another
platform-based ifdef, so if that is anathema, it can be replaced by more
autoconf hackery.
The patch as-is compiles targeting on vxworks and bootstraps on a native
x86_64-linux-gnu build (which makes sense, since it doesn't touch
anything for non-vxworks).
Gerald Pfeifer has volunteered to apply the patch if approved.
Also, in an earlier message [1] Janne Blomqvist mentioned that newer
versions of VxWorks do have the variadic open(), and this is true.
However, as far as I know, this version is still not available for
kernel modules, only real-time processes.
Thanks,
Robert Mason
>From ad3b2df4d172eea2e0edfd61153133b25a7ed640 Mon Sep 17 00:00:00 2001
From: rbmj
Date: Wed, 30 May 2012 08:42:37 -0400
Subject: [PATCH 3/5] Make changes to gcov to allow compilation targeting
vxworks.
gcc/gcov-io.c: add mode argument to open() on vxworks
libgcc/libgcov.c: fall back to single argument mkdir() on vxworks
---
gcc/ChangeLog|5 +
gcc/gcov-io.c|4
libgcc/ChangeLog |5 +
libgcc/libgcov.c |2 +-
4 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 71451d2..c362fc6 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,10 @@
2012-05-30 Robert Mason
+ * gcov-io.c (gcov_open): VxWorks does not have variadic open(), so pass
+ in a mode argument (ignored for O_RDONLY) on that platform.
+
+2012-05-30 Robert Mason
+
* config/rs6000/vxworks.h: Fix bad macro SUBSUBTARGET_OVERRIDE_OPTIONS.
2012-05-29 Joseph Myers
diff --git a/gcc/gcov-io.c b/gcc/gcov-io.c
index 37c1c3e..823067a 100644
--- a/gcc/gcov-io.c
+++ b/gcc/gcov-io.c
@@ -92,7 +92,11 @@ gcov_open (const char *name, int mode)
{
/* Read-only mode - acquire a read-lock. */
s_flock.l_type = F_RDLCK;
+#ifdef __VXWORKS__
+ fd = open (name, O_RDONLY, 0666);
+#else
fd = open (name, O_RDONLY);
+#endif
}
else
{
diff --git a/libgcc/ChangeLog b/libgcc/ChangeLog
index 5c048f5..04a6653 100644
--- a/libgcc/ChangeLog
+++ b/libgcc/ChangeLog
@@ -1,3 +1,8 @@
+2012-05-30 Robert Mason
+
+* libgcov.c (create_file_directory): VxWorks does not have two-argument
+mkdir, so fall back to the single-argument call on that platform.
+
2012-05-25 Ian Lance Taylor
* config/i386/morestack.S (__morestack_non_split): Check whether
diff --git a/libgcc/libgcov.c b/libgcc/libgcov.c
index 8ed8971..27117b4 100644
--- a/libgcc/libgcov.c
+++ b/libgcc/libgcov.c
@@ -133,7 +133,7 @@ create_file_directory (char *filename)
/* Try to make directory if it doesn't already exist. */
if (access (filename, F_OK) == -1
-#ifdef TARGET_POSIX_IO
+#if defined(TARGET_POSIX_IO) && !defined(__VXWORKS__)
&& mkdir (filename, 0755) == -1
#else
&& mkdir (filename) == -1
--
1.7.5.4
Fix typo in intrinsics/time_1.h
Hi all, In libgfortran/intrinsics/time_1.h:181, there is a typo that refers to user_usecs (should be user_usec). This patch fixes it. I don't have commit access, so someone please apply this for me. It should be obvious. Robert Mason diff --git a/libgfortran/intrinsics/time_1.h b/libgfortran/intrinsics/time_1.h index 98a20d2..920b175 100644 --- a/libgfortran/intrinsics/time_1.h +++ b/libgfortran/intrinsics/time_1.h @@ -178,7 +178,7 @@ gf_cputime (long *user_sec, long *user_usec, long *system_sec, long *system_usec struct timespec ts; int err = clock_gettime (CLOCK_PROCESS_CPUTIME_ID, &ts); *user_sec = ts.tv_sec; - *user_usecs = ts.tv_nsec / 1000; + *user_usec = ts.tv_nsec / 1000; *system_sec = *system_usec = 0; return err;
[Patch] Add AC_ARG_ENABLE for libstdc++-v3
This patch adds an AC_ARG_ENABLE option to build/not build
libstdc++-v3. I wrote the patch in order to allow the user to override
the automatic disable for libstdc++-v3 for certain targets.
Patch is against configure.ac in trunk.
Robert Mason
>From 69c085f3742e94501f4a202d1321e143afe9a115 Mon Sep 17 00:00:00 2001
From: rbmj
Date: Tue, 22 May 2012 16:32:02 -0400
Subject: [PATCH] Added --enable-libstdc++-v3 option.
---
configure.ac | 38 +-
1 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/configure.ac b/configure.ac
index 378e9f5..c06b400 100644
--- a/configure.ac
+++ b/configure.ac
@@ -425,6 +425,15 @@ AC_ARG_ENABLE(libssp,
ENABLE_LIBSSP=$enableval,
ENABLE_LIBSSP=yes)
+AC_ARG_ENABLE(libstdc++-v3,
+AS_HELP_STRING([--disable-libstdc++-v3],
+ [do not build libstdc++-v3 directory]),
+ENABLE_LIBSTDCXX=$enableval,
+ENABLE_LIBSTDCXX=default)
+if test "${ENABLE_LIBSTDCXX}" = "no" ; then
+ noconfigdirs="$noconfigdirs libstdc++-v3"
+fi
+
# Save it here so that, even in case of --enable-libgcj, if the Java
# front-end isn't enabled, we still get libgcj disabled.
libgcj_saved=$libgcj
@@ -544,19 +553,22 @@ case "${target}" in
esac
# Disable libstdc++-v3 for some systems.
-case "${target}" in
- *-*-vxworks*)
-# VxWorks uses the Dinkumware C++ library.
-noconfigdirs="$noconfigdirs target-libstdc++-v3"
-;;
- arm*-wince-pe*)
-# the C++ libraries don't build on top of CE's C libraries
-noconfigdirs="$noconfigdirs target-libstdc++-v3"
-;;
- avr-*-*)
-noconfigdirs="$noconfigdirs target-libstdc++-v3"
-;;
-esac
+# Allow user to override this if they pass --enable-libstdc++-v3
+if test "${ENABLE_LIBSTDCXX}" = "default" ; then
+ case "${target}" in
+*-*-vxworks*)
+ # VxWorks uses the Dinkumware C++ library.
+ noconfigdirs="$noconfigdirs target-libstdc++-v3"
+ ;;
+arm*-wince-pe*)
+ # the C++ libraries don't build on top of CE's C libraries
+ noconfigdirs="$noconfigdirs target-libstdc++-v3"
+ ;;
+avr-*-*)
+ noconfigdirs="$noconfigdirs target-libstdc++-v3"
+ ;;
+ esac
+fi
# Disable Fortran for some systems.
case "${target}" in
--
1.7.5.4
Re: [Patch, libgfortran] PR53445/53444 - Fix compilation on VxWorks
On 05/22/2012 03:42 PM, Janne Blomqvist wrote: On Tue, May 22, 2012 at 10:33 PM, Janne Blomqvist wrote: On Tue, May 22, 2012 at 5:57 PM, Tobias Burnus wrote: On 05/22/2012 03:06 PM, Tobias Burnus wrote: The attached patches fix compilation issues on VxWorks. a) VxWorks has strerror_r but contrary to POSIX, the function in VxWorks (at least in older versions) takes only two arguments: errnum and buf and not also the buffer length. I added a configure check for that variant. I forgot to attach that patch. Now with patch and automake 1.11.1 for the generated files. Tobias For the a) patch (strerror_r): The configure.ac diff occurs twice in the patch, and the patch file has DOS line endings. Also, based on some googling the vxworks 2-arg strerror_r returns OK or ERROR (an enum, I presume). So the trick with builtin_choose_expr is both wrong and unnecessary. Thus I'd replace +#elif defined(HAVE_STRERROR_R_2ARGS) + return +__builtin_choose_expr (__builtin_classify_type (strerror_r (0, buf)) + == 5, + /* char*-returning strerror_r() */ + strerror_r (errnum, buf), + /* int-returning strerror_r () */ + (strerror_r (errnum, buf), buf)); with #elif defined(HAVE_STRERROR_R_2ARGS) if (strerror_r (errnum, buf) == OK) return buf; return NULL; Googling some more, it seems the vxworks STATUS is just a typedef for int, so I guess the original patch works. Also the error checking is not useful here, so we could do just #elif defined(HAVE_STRERROR_R_2ARGS) strerror_r (errnum, buf); return buf; All the proposed solutions work for me. Robert Mason
[Patch, libgfortran] Add FPU Support for powerpc
Hi everyone,
This patch adds FPU support for powerpc on platforms that do not have
glibc. It is basically the same code as glibc has. The motivation for
this was that right now there is no fpu-target.h that works for
powerpc-*-vxworks.
Again, 90% of this code comes directly from glibc. But on vxworks
targets there is no glibc.
I also patched the configure.host script in order to add this in.
Any opinions?
Robert Mason
>From f9449738730fa0d460a30affa826a157bf97cf62 Mon Sep 17 00:00:00 2001
From: rbmj
Date: Mon, 21 May 2012 15:56:06 -0400
Subject: [PATCH 3/6] Add FPU Support for PPC on VxWorks
libgfortran/config/fpu-ppc.h:
Started work on a fpu-target.h that will work for VxWorks on PPC.
90% of it is stolen from glibc. I just took the necessary pieces
and added the right VxWorks glue. I made as few changes to the
glibc code as possible in order to avoid introducing a bug.
The VxWorks part seems to be correct, but I don't have a whole
lot of experience in this area and documentation is incomplete.
libgfortran/configure.host:
This just adds fpu-ppc.h to the list of targets. For some
reason, my powerpc-wrs-vxworks is getting mis-identified as
AIX, even though it does not have the functions, so I'll also
have to work on a patch for configure.ac. I'll check on that.
Also, I put it before glibc so that glibc targets will get
to use glibc and not rely on my cruft.
---
libgfortran/config/fpu-ppc.h | 407 ++
libgfortran/configure.host | 11 ++
2 files changed, 418 insertions(+), 0 deletions(-)
create mode 100644 libgfortran/config/fpu-ppc.h
diff --git a/libgfortran/config/fpu-ppc.h b/libgfortran/config/fpu-ppc.h
new file mode 100644
index 000..f27df7f
--- /dev/null
+++ b/libgfortran/config/fpu-ppc.h
@@ -0,0 +1,407 @@
+/* FPU-related code for systems without glibc on powerpc.
+ Copyright (C) 1997, 1998, 1999, 2008 Free Software Foundation, Inc.
+
+This file is part of the GNU Fortran runtime library (libgfortran).
+This file incorporates code from the GNU C Library (glibc) under the GNU LGPL.
+
+Libgfortran is free software; you can redistribute it and/or
+modify it under the terms of the GNU General Public
+License as published by the Free Software Foundation; either
+version 3 of the License, or (at your option) any later version.
+
+Libgfortran is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
+<http://www.gnu.org/licenses/>. */
+
+/* FPU Types/Constants: */
+
+/* Type representing exception flags. */
+typedef unsigned int fexcept_t;
+
+/* Type representing floating-point environment. We leave it as 'double'
+ for efficiency reasons (rather than writing it to a 32-bit integer). */
+typedef double fenv_t;
+
+/* We want to specify the bit pattern of the __fe_*_env constants, so
+ pretend they're really `long long' instead of `double'. */
+
+/* If the default argument is used we use this value. */
+const unsigned long long __fe_dfl_env __attribute__ ((aligned (8))) =
+0xfff8ULL;
+#define FE_DFL_ENV ((double*)(&__fe_dfl_env))
+
+/* Floating-point environment where all exceptions are enabled. Note that
+ this is not sufficient to give you SIGFPE. */
+const unsigned long long __fe_enabled_env __attribute__ ((aligned (8))) =
+0xfff800f8ULL;
+# define FE_ENABLED_ENV ((double*)(&__fe_enabled_env))
+
+/* Floating-point environment with (processor-dependent) non-IEEE floating
+ point. */
+const unsigned long long __fe_nonieee_env __attribute__ ((aligned (8))) =
+0xfff80004ULL;
+# define FE_NONIEEE_ENV ((double*)(&__fe_nonieee_env))
+
+/* Provide __fe_mask_env and __fe_nomask_env */
+#ifdef __VXWORKS__
+
+/* These are based loosly off of glibc
+
+ see also glibc/sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu/fe{,no}mask.c
+ */
+
+#include
+#include
+
+#if !defined (_PPC_MSR_FE0) || !defined (_PPC_MSR_FE1)
+#error FPU Support does not appear to exist on target platform
+#else
+
+const fenv_t *
+__fe_nomask_env(void)
+{
+ UINT32 msr = vxMsrGet();
+ msr |= _PPC_MSR_FE0 | _PPC_MSR_FE1;
+ vxMsrSet(msr);
+ return FE_ENABLED_ENV;
+}
+
+const fenv_t *
+__fe_nomask_env(void)
+{
+ UINT32 msr = vxMsrGet();
+ msr &= ~(_PPC_MSR_FE0 | _PPC_MSR_FE1);
+ vxMsrSet(msr);
+ return FE_DFL_ENV;
+}
+
+#endif
+
+#else
+
+/* VxWorks is the only OS that this header s
Re: [Patch, libgfortran] Pass mode in "open" for O_CREAT and on VxWorks
On 05/16/2012 08:06 AM, rbmj wrote:
On 05/16/2012 07:26 AM, Janne Blomqvist wrote:
On Wed, May 16, 2012 at 1:03 PM, Tobias Burnus wrote:
On 05/16/2012 08:45 AM, Janne Blomqvist wrote:
IMHO it would be cleaner if you instead somewhere in the beginning of
unix.c did
#ifdef __VXWORKS__
/* open is not a variadic function on vxworks (or something...) */
#define open(path, flags) open(path, flags, 0666)
#endif
Untested, but AFAICS it should work (unless I'm missing something wrt
macro expansion, which of course is quite possible).
Testing shows that CPP does not like it:
$ cpp
#define a(x,y) a(x,y,0666)
a(1,2)
a(1,2,3)
# 1 ""
# 1 ""
# 1 ""
a(1,2,0666)
:3:8: error: macro "a" passed 3 arguments, but takes just 2
Ah, bummer. We have something roughly similiar for snprintf (see
libgfortran.h), but it seems that it works slightly differently due to
using a variadic macro etc. So it seems this idea will not work,
sorry.
Actually, this works for me:
$ cat test.c
#include
void a(int b, int c, int d) {
printf("%i\t%i\t%i", b, c, d);
}
#define a(b, c) (a)(b, c, 3)
int main() {
a(1, 2);
return 0;
}
$ gcc test.c -o a.out
$ ./a.out
1 2 3
Just realized that mine doesn't work either. Sorry, wasn't looking
closely enough :-( The closest one can get is an inline overload, but
that requires c++.
On a side note, isn't this what autoconf is designed for?
Robert Mason
Re: [Patch, libgfortran] Pass mode in "open" for O_CREAT and on VxWorks
On 05/16/2012 07:26 AM, Janne Blomqvist wrote:
On Wed, May 16, 2012 at 1:03 PM, Tobias Burnus wrote:
On 05/16/2012 08:45 AM, Janne Blomqvist wrote:
IMHO it would be cleaner if you instead somewhere in the beginning of
unix.c did
#ifdef __VXWORKS__
/* open is not a variadic function on vxworks (or something...) */
#define open(path, flags) open(path, flags, 0666)
#endif
Untested, but AFAICS it should work (unless I'm missing something wrt
macro expansion, which of course is quite possible).
Testing shows that CPP does not like it:
$ cpp
#define a(x,y) a(x,y,0666)
a(1,2)
a(1,2,3)
# 1 ""
# 1 ""
# 1 ""
a(1,2,0666)
:3:8: error: macro "a" passed 3 arguments, but takes just 2
Ah, bummer. We have something roughly similiar for snprintf (see
libgfortran.h), but it seems that it works slightly differently due to
using a variadic macro etc. So it seems this idea will not work,
sorry.
Actually, this works for me:
$ cat test.c
#include
void a(int b, int c, int d) {
printf("%i\t%i\t%i", b, c, d);
}
#define a(b, c) (a)(b, c, 3)
int main() {
a(1, 2);
return 0;
}
$ gcc test.c -o a.out
$ ./a.out
1 2 3
The significance is in the parentheses in the macro definition.
However, I was told that VxWorks 6.6 *does* have access() [1] and it is
defined in unistd.h of 6.3. (Recall that fallback_access does not get
complied if HAS_ACCESS is true.) He didn't know whether it is
available in
all versions of VxWorks, however. Additionally, he has heard about
gfortran
issues (but has no experience with them); and he promised to compile
everything to see whether everything works.
[1]
http://www-ad.fnal.gov/controls/micro_p/manuals/vxworks_application_api_reference_6.6.pdf
Interestingly, according to that document open() also has the POSIXly
correct varargs prototype. So apparently the old 3-argument prototype
was used only in some older vxworks version? Since the document above
is from 2007, one wonders how long ago did the prototype change, and
how much new development is done on these older vxworks versions?
In light of the CPP issue and the HAS_ACCESAS: Shall I only commit the
second part or also the VxWorks part?
IMHO lets do only the second part now, and wait for someone with
vxworks experience to pop in and explain what changes are necessary,
and which vxworks versions are worth considering to support.
I'm using the VxWorks 6.3 headers. The reason for this is that these
headers are available at [1], and that this is the version of VxWorks
used for FRC. I can also say that these headers do NOT contain the
POSIX-ly correct version of open(). Additionally, they do NOT have the
POSIX-ly correct version of ioctl(), so something like the following is
needed:
#define ioctl(a, b, c) (ioctl)(a, b, (int)c)
To explain FRC- I'm a high school student on a FIRST Robotics
Competition team working on getting a full gcc4 toolchain, as the
provided toolchain is gcc 3.4 and windows binaries . Please don't hold
my age/experience (or lack thereof) against me. So if you're looking
for users, there's probably around 100,000 of us high school students in
FRC around the world
[1]: ftp://ftp.ni.com/pub/devzone/tut/updated_vxworks63gccdist.zip
Robert Mason
Re: Patches for building libstdc++ on vxWorks
On 05/01/2012 09:14 PM, rbmj wrote: These minor changes are needed to build libstdc++ on vxWorks. Note- these diffs are based off of gcc 4.7.0 Bump? I'm sorry for not following all the protocols, but I did create a bug afterwards and I've waited a while. I know it's trivial, but to me it seems like that should make it easy... And I also mis-spoke in my original email. I did not even look closely at the patches I'd made - they're for gcov. I apologize for being an idiot :D Thank you all, -- rbmj
Patches for building libstdc++ on vxWorks
These minor changes are needed to build libstdc++ on vxWorks.
Note- these diffs are based off of gcc 4.7.0
diff -durp -x '*~' a/gcc/gcov-io.c b/gcc/gcov-io.c
--- a/gcc/gcov-io.c2011-04-06 11:05:18.0 -0500
+++ b/gcc/gcov-io.c2012-01-15 21:27:41.407688488 -0500
@@ -92,7 +92,11 @@ gcov_open (const char *name, int mode)
{
/* Read-only mode - acquire a read-lock. */
s_flock.l_type = F_RDLCK;
+#ifdef __VXWORKS__
+ fd = open (name, O_RDONLY, 0666);
+#else
fd = open (name, O_RDONLY);
+#endif
}
else
{
diff -durp -x '*~' a/libgcc/libgcov.c b/libgcc/libgcov.c
--- a/libgcc/libgcov.c2011-01-04 13:05:06.0 -0500
+++ b/libgcc/libgcov.c2012-01-15 17:54:11.566928799 -0500
@@ -119,7 +119,7 @@ create_file_directory (char *filename)
/* Try to make directory if it doesn't already exist. */
if (access (filename, F_OK) == -1
-#ifdef TARGET_POSIX_IO
+#if defined(TARGET_POSIX_IO) && !defined(__VXWORKS__)
&& mkdir (filename, 0755) == -1
#else
&& mkdir (filename) == -1
--
rbmj
