[PATCH 0/5] some vxworks patches

[PATCH 0/5] some vxworks patches

[Rasmus Villemoes]

Hi Olivier et al

I'm having quite a bit of trouble getting gcc 10 to build for our
vxworks 5 (5.5.1) target. The first thing I hit is

#if !defined(_WRS_VXWORKS_MAJOR)
#error "VxWorks version macros needed but not defined"
#endif

Our version.h doesn't define that macro (however, there's a
_WRS_VXWORKS_5_X defined in vxWorks.h). Amusingly, a few of the system
headers do mention _WRS_VXWORKS_MAJOR, e.g.

getOptLib.h:#include "vxWorks.h" /* for _WRS_VXWORKS_MAJOR, if defined. */

and everywhere in the headers that use that macro, they are careful to
do "#if defined (_WRS_VXWORKS_MAJOR) && (_WRS_VXWORKS_MAJOR >= 6)".

For now, I've just monkey-patched _vxworks-versions.h to get the build
past that - I suppose what I should do is to patch our version.h
system header instead to provide those two macros.

But most of the gthread stuff simply doesn't build against our
headers. These five patches, and a bogus definition of WIND_USR
environment variable (-mrtp doesn't make sense for us, but
vx_crtbegin-rtp.o still gets built and that fails if WIND_USR doesn't
exist) get the build a little further - I then fail to build
libstdc++, but I'd like some feedback on whether vxworks 5 is even
supposed to be (still) supported before digging further.


Rasmus Villemoes (5):
  libgcc: vxwors: stub out VX_ENTER_TLS_DTOR for vxworks 5
  gthr-vxworks.h: fix leftover _VXW_PRE_69
  gthr-vxworks.c: add include of taskLib.h
  libgcc: vxworks: don't set __GTHREAD_HAS_COND for vxworks 5.x
  libgcc: vxworks: don't set __GTHREAD_CXX0X for vxworks 5.x

 libgcc/config/gthr-vxworks-cond.c   |  4 ++++
 libgcc/config/gthr-vxworks-thread.c |  4 ++++
 libgcc/config/gthr-vxworks-tls.c    |  5 +++++
 libgcc/config/gthr-vxworks.c        |  1 +
 libgcc/config/gthr-vxworks.h        | 10 +++++++---
 5 files changed, 21 insertions(+), 3 deletions(-)

-- 
2.23.0

[PATCH 1/5] libgcc: vxwors: stub out VX_ENTER_TLS_DTOR for vxworks 5

[Rasmus Villemoes]

Commit 806dd0472f56 (Improve the thread support for VxWorks)
introduced calls of (on vxworks 5 at least) non-existing
__gthread_enter_tls_dtor_context/__gthread_leave_tls_dtor_context ;
the code used to call
__gthread_enter_tsd_dtor_context/__gthread_leave_tsd_dtor_context. Those
are simply no-ops (we simply use the definitions which are provided in
contrib/gthr_supp_vxw_5x.c), so we can fix this by nop'ing out
VX_ENTER_TLS_DTOR/VX_LEAVE_TLS_DTOR for vxworks 5.x.
---
 libgcc/config/gthr-vxworks-tls.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/libgcc/config/gthr-vxworks-tls.c b/libgcc/config/gthr-vxworks-tls.c
index fac25e305a0..726304166fc 100644
--- a/libgcc/config/gthr-vxworks-tls.c
+++ b/libgcc/config/gthr-vxworks-tls.c
@@ -117,8 +117,13 @@ extern void __gthread_leave_tls_dtor_context (void);
 #define VX_GET_TLS_DATA() __gthread_get_tls_data()
 #define VX_SET_TLS_DATA(x) __gthread_set_tls_data(x)
 
+#ifdef _VXWORKS_MAJOR_EQ(5)
+#define VX_ENTER_TLS_DTOR()
+#define VX_LEAVE_TLS_DTOR()
+#else
 #define VX_ENTER_TLS_DTOR() __gthread_enter_tls_dtor_context ()
 #define VX_LEAVE_TLS_DTOR() __gthread_leave_tls_dtor_context ()
+#endif
 
 #endif
 
-- 
2.23.0

[PATCH 2/5] gthr-vxworks.h: fix leftover _VXW_PRE_69

[Rasmus Villemoes]

_VXW_PRE_69 was introduced in 806dd0472f, then replaced by
_VXWORKS_PRE(6,9) in abb6c3eecf, but this one was missed.

Fixes: abb6c3eecf (Introduce an internal API for VxWorks version checks)
---
 libgcc/config/gthr-vxworks.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgcc/config/gthr-vxworks.h b/libgcc/config/gthr-vxworks.h
index 8b55fc55407..e38174730bf 100644
--- a/libgcc/config/gthr-vxworks.h
+++ b/libgcc/config/gthr-vxworks.h
@@ -286,7 +286,7 @@ typedef struct
 typedef __gthread_tcb *__gthread_t;
 
 /* Typedefs specific to different vxworks versions.  */
-#if _VXW_PRE_69
+#if _VXWORKS_PRE(6,9)
   typedef int _Vx_usr_arg_t;
   #define TASK_ID_NULL ((TASK_ID)NULL)
   #define SEM_ID_NULL ((SEM_ID)NULL)
-- 
2.23.0

[PATCH 3/5] gthr-vxworks.c: add include of taskLib.h

[Rasmus Villemoes]

Fix

gcc-src/libgcc/config/gthr-vxworks.c:65:7: warning: implicit declaration of function 'taskDelay'; did you mean 'sysDelay'? [-Wimplicit-function-declaration]
   65 |       taskDelay (1);
---
 libgcc/config/gthr-vxworks.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libgcc/config/gthr-vxworks.c b/libgcc/config/gthr-vxworks.c
index 9b47ec8e9e9..4e73108d907 100644
--- a/libgcc/config/gthr-vxworks.c
+++ b/libgcc/config/gthr-vxworks.c
@@ -33,6 +33,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #if defined(__GTHREADS)
 
 #include <vxWorks.h>
+#include <taskLib.h>
 
 #ifndef __RTP__
 # include <vxLib.h>
-- 
2.23.0

[PATCH 4/5] libgcc: vxworks: don't set __GTHREAD_HAS_COND for vxworks 5.x

[Rasmus Villemoes]

The vxworks-cond.c file fails to compile for vxworks 5.x:

libgcc/config/gthr-vxworks-cond.c:29:
./gthr-default.h:274:3: error: unknown type name 'TASK_ID'
  274 |   TASK_ID task_id;
      |   ^~~~~~~

There is a TASK_ID typedef in our system headers, but (1) is is
commented out, (2) lives in some obscure header that nothing really
pulls in and (3) it is defined as a "struct wind_task *", which isn't
really consistent with taskCreate() returning an int.

In order to allow building gcc, let's just disable __GTHREAD_HAS_COND
for vxworks 5.x. To simplify the makefile fragments, keep including
gthr-vxworks-cond.c, but guard the actual code by __GTHREAD_HAS_COND -
that way, the logic for deciding whether to support gthread condition
variables is kept in gthr-vxworks.h.
---
 libgcc/config/gthr-vxworks-cond.c | 4 ++++
 libgcc/config/gthr-vxworks.h      | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/libgcc/config/gthr-vxworks-cond.c b/libgcc/config/gthr-vxworks-cond.c
index d65d07aebc3..f0585624c05 100644
--- a/libgcc/config/gthr-vxworks-cond.c
+++ b/libgcc/config/gthr-vxworks-cond.c
@@ -31,6 +31,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 
 /* --------------------------- Condition Variables ------------------------ */
 
+#if __GTHREAD_HAS_COND
+
 void
 __gthread_cond_init (__gthread_cond_t *cond)
 {
@@ -81,3 +83,5 @@ __gthread_cond_wait_recursive (__gthread_cond_t *cond,
 {
   return __gthread_cond_wait (cond, mutex);
 }
+
+#endif
diff --git a/libgcc/config/gthr-vxworks.h b/libgcc/config/gthr-vxworks.h
index e38174730bf..91e3d94ac67 100644
--- a/libgcc/config/gthr-vxworks.h
+++ b/libgcc/config/gthr-vxworks.h
@@ -234,6 +234,8 @@ extern int __gthread_setspecific (__gthread_key_t __key, void *__ptr);
 
 /* ------------------ Base condition variables support ------------------- */
 
+#if _VXWORKS_MAJOR_GE(6)
+
 #define __GTHREAD_HAS_COND 1
 
 typedef SEM_ID __gthread_cond_t;
@@ -254,6 +256,8 @@ extern int __gthread_cond_wait (__gthread_cond_t *cond,
 extern int __gthread_cond_wait_recursive (__gthread_cond_t *cond,
 					  __gthread_recursive_mutex_t *mutex);
 
+#endif /* _VXWORKS_MAJOR_GE(6) */
+
 /* -----------------------  C++0x thread support ------------------------- */
 
 /* We do not support C++0x threads on that VxWorks 653, which we can
-- 
2.23.0

[PATCH 5/5] libgcc: vxworks: don't set __GTHREAD_CXX0X for vxworks 5.x

[Rasmus Villemoes]

gthr-vxworks-thread.c fails to compile for vxworks 5.x:

libgcc/config/gthr-vxworks-thread.c:268:14: error: 'VX_USR_TASK_OPTIONS' undeclared (first use in this function)
  268 |   options &= VX_USR_TASK_OPTIONS;
      |              ^~~~~~~~~~~~~~~~~~~

libgcc/config/gthr-vxworks-thread.c:282:3: error: unknown type name 'TASK_ID'
  282 |   TASK_ID task_id = taskCreate (NULL,
      |   ^~~~~~~

As for __GTHREAD_HAS_COND, use __GTHREAD_CXX0X to guard the actual
contents of gthr-vxworks-thread.c. That should also allow dropping the
t-gthr-vxworksae fragment and simply use t-gthr-vxworks.
---
 libgcc/config/gthr-vxworks-thread.c | 4 ++++
 libgcc/config/gthr-vxworks.h        | 4 ++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/libgcc/config/gthr-vxworks-thread.c b/libgcc/config/gthr-vxworks-thread.c
index 8544b03dd18..183198577eb 100644
--- a/libgcc/config/gthr-vxworks-thread.c
+++ b/libgcc/config/gthr-vxworks-thread.c
@@ -30,6 +30,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 #include "gthr.h"
 #include <taskLib.h>
 
+#if __GTHREAD_CXX0X
+
 #define __TIMESPEC_TO_NSEC(timespec) \
   ((long long)timespec.tv_sec * 1000000000 + (long long)timespec.tv_nsec)
 
@@ -347,3 +349,5 @@ __gthread_detach (__gthread_t __threadid)
 
   return OK;
 }
+
+#endif
diff --git a/libgcc/config/gthr-vxworks.h b/libgcc/config/gthr-vxworks.h
index 91e3d94ac67..14e7d54b022 100644
--- a/libgcc/config/gthr-vxworks.h
+++ b/libgcc/config/gthr-vxworks.h
@@ -263,7 +263,7 @@ extern int __gthread_cond_wait_recursive (__gthread_cond_t *cond,
 /* We do not support C++0x threads on that VxWorks 653, which we can
    recognize by VTHREADS being defined.  */
 
-#ifndef VTHREADS
+#if _VXWORKS_MAJOR_GE(6) && !defined(VTHREADS)
 
 #define __GTHREADS_CXX0X 1
 
@@ -326,7 +326,7 @@ extern int __gthread_detach (__gthread_t thread);
 
 extern __gthread_t __gthread_self (void);
 
-#endif
+#endif /* _VXWORKS_MAJOR_GE(6) && !defined(VTHREADS) */
 
 #ifdef __cplusplus
 }
-- 
2.23.0

Re: [PATCH 0/5] some vxworks patches

[Olivier Hainque]

Hi Rasmus,

> On 26 May 2020, at 16:52, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
> 
> Hi Olivier et al
> 
> I'm having quite a bit of trouble getting gcc 10 to build for our
> vxworks 5 (5.5.1) target.

Thanks for your message.

VxWorks 5 was transitioned
to End Of Life long ago so we're not testing for it any more.

I have more input to convey but can't do this just now. I'll get
back to you on this next week, probably through the gcc-patches list.

Thanks,

Olivier

Re: [PATCH 0/5] some vxworks patches

[Olivier Hainque]

Hi Rasmus,

> On 26 May 2020, at 16:52, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
> 
> Hi Olivier et al
> 
> I'm having quite a bit of trouble getting gcc 10 to build for our
> vxworks 5 (5.5.1) target. The first thing I hit is
> 
> #if !defined(_WRS_VXWORKS_MAJOR)
> #error "VxWorks version macros needed but not defined"
> #endif
> 
> Our version.h doesn't define that macro (however, there's a
> _WRS_VXWORKS_5_X defined in vxWorks.h). Amusingly, a few of the system
> headers do mention _WRS_VXWORKS_MAJOR, e.g.
> 
> getOptLib.h:#include "vxWorks.h" /* for _WRS_VXWORKS_MAJOR, if defined. */
> 
> and everywhere in the headers that use that macro, they are careful to
> do "#if defined (_WRS_VXWORKS_MAJOR) && (_WRS_VXWORKS_MAJOR >= 6)".
> 
> For now, I've just monkey-patched _vxworks-versions.h to get the build
> past that - I suppose what I should do is to patch our version.h
> system header instead to provide those two macros.
> 
> But most of the gthread stuff simply doesn't build against our
> headers. These five patches, and a bogus definition of WIND_USR
> environment variable (-mrtp doesn't make sense for us, but
> vx_crtbegin-rtp.o still gets built and that fails if WIND_USR doesn't
> exist) get the build a little further - I then fail to build
> libstdc++, but I'd like some feedback on whether vxworks 5 is even
> supposed to be (still) supported before digging further.

Unfortunately, no, not really: while we don't break it
intentionally, it was transitioned to End Of Life a couple
of years a ago and we don't test on such configurations
any more.

We are gradually going to a similar path for VxWorks 6, with 6.8
EOL since July 2019 and 6.9 turned Legacy early 2020 after ~9 years
out.

Your message comes in timely - I was about to send a note
mentioning this soon now, as we are starting a transition of
all our production toolchains to gcc-10 and we are resuming
posting updates upstream as stage1 has just reopened.

The system environment on 5 and 6 is essentially frozen. Maintaining
new versions of gcc operational on such legacy versions is increasingly
difficult with every release as incompatibilities of various degrees
of subtlety keep creeping in.

Build failures are one thing and can often be addressed, but we have
witnessed, for example, issues with newer dwarf constructs incorrectly
processed by the system unwind lib or wrong code gen problems on arm
for vx6 related to the use of a long deprecated ABI.

We can take patches that are reported as helping such cases,
as we have done in the past, as long as they are localized and look
generally good. But as I mentioned, we are not in a position to
really test vx5 configurations any more.

The series you sent seem to fit well and I'm getting to them more
closely.

Thanks

Olivier

> Rasmus Villemoes (5):
>  libgcc: vxwors: stub out VX_ENTER_TLS_DTOR for vxworks 5
>  gthr-vxworks.h: fix leftover _VXW_PRE_69
>  gthr-vxworks.c: add include of taskLib.h
>  libgcc: vxworks: don't set __GTHREAD_HAS_COND for vxworks 5.x
>  libgcc: vxworks: don't set __GTHREAD_CXX0X for vxworks 5.x
> 
> libgcc/config/gthr-vxworks-cond.c   |  4 ++++
> libgcc/config/gthr-vxworks-thread.c |  4 ++++
> libgcc/config/gthr-vxworks-tls.c    |  5 +++++
> libgcc/config/gthr-vxworks.c        |  1 +
> libgcc/config/gthr-vxworks.h        | 10 +++++++---
> 5 files changed, 21 insertions(+), 3 deletions(-)
> 
> -- 
> 2.23.0
> 

Re: [PATCH 2/5] gthr-vxworks.h: fix leftover _VXW_PRE_69

[Olivier Hainque]

> On 26 May 2020, at 16:52, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
> 
> _VXW_PRE_69 was introduced in 806dd0472f, then replaced by
> _VXWORKS_PRE(6,9) in abb6c3eecf, but this one was missed.
> 
> Fixes: abb6c3eecf (Introduce an internal API for VxWorks version checks)
> ---
> libgcc/config/gthr-vxworks.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libgcc/config/gthr-vxworks.h b/libgcc/config/gthr-vxworks.h
> index 8b55fc55407..e38174730bf 100644
> --- a/libgcc/config/gthr-vxworks.h
> +++ b/libgcc/config/gthr-vxworks.h
> @@ -286,7 +286,7 @@ typedef struct
> typedef __gthread_tcb *__gthread_t;
> 
> /* Typedefs specific to different vxworks versions.  */
> -#if _VXW_PRE_69
> +#if _VXWORKS_PRE(6,9)
>   typedef int _Vx_usr_arg_t;
>   #define TASK_ID_NULL ((TASK_ID)NULL)
>   #define SEM_ID_NULL ((SEM_ID)NULL)

Ok, thanks.

Olivier

Re: [PATCH 0/5] some vxworks patches

[Rasmus Villemoes]

On 03/06/2020 19.41, Olivier Hainque wrote:
> Hi Rasmus,
> 
>> On 26 May 2020, at 16:52, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
>>
>> libstdc++, but I'd like some feedback on whether vxworks 5 is even
>> supposed to be (still) supported before digging further.
> 
> Unfortunately, no, not really: while we don't break it
> intentionally, it was transitioned to End Of Life a couple
> of years a ago and we don't test on such configurations
> any more.
> 
> We are gradually going to a similar path for VxWorks 6, with 6.8
> EOL since July 2019 and 6.9 turned Legacy early 2020 after ~9 years
> out.

Hi Olivier,

Thanks for the answer, though obviously not what I was hoping for.

Just for the record, who exactly are "we" above?

> Your message comes in timely - I was about to send a note
> mentioning this soon now, as we are starting a transition of
> all our production toolchains to gcc-10 and we are resuming
> posting updates upstream as stage1 has just reopened.
> 
> The system environment on 5 and 6 is essentially frozen. Maintaining
> new versions of gcc operational on such legacy versions is increasingly
> difficult with every release as incompatibilities of various degrees
> of subtlety keep creeping in.
>
> Build failures are one thing and can often be addressed, but we have
> witnessed, for example, issues with newer dwarf constructs incorrectly
> processed by the system unwind lib or wrong code gen problems on arm
> for vx6 related to the use of a long deprecated ABI.
> 
> We can take patches that are reported as helping such cases,
> as we have done in the past, as long as they are localized and look
> generally good. But as I mentioned, we are not in a position to
> really test vx5 configurations any more.

I (and my customer) am willing to put in some effort to make (or keep)
gcc working for vxworks 5. In case the ifdeffery in the existing
vxworks-related files becomes too unwieldy, would it be possible to
create a separate vxworks5 target, similar to the existing vxworksae
variant?

Thanks,
Rasmus

Re: [PATCH 0/5] some vxworks patches

[Olivier Hainque]

Hi Rasmus,

> On 04 Jun 2020, at 15:31, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
> 
>> Unfortunately, no, not really: while we don't break it
>> intentionally, it was transitioned to End Of Life a couple
>> of years a ago and we don't test on such configurations
>> any more.
>> 
>> We are gradually going to a similar path for VxWorks 6, with 6.8
>> EOL since July 2019 and 6.9 turned Legacy early 2020 after ~9 years
>> out.
> 
> Hi Olivier,
> 
> Thanks for the answer, though obviously not what I was hoping for.

> Just for the record, who exactly are "we" above?

AdaCore. 

>> We can take patches that are reported as helping such cases,
>> as we have done in the past, as long as they are localized and look
>> generally good. But as I mentioned, we are not in a position to
>> really test vx5 configurations any more.
> 
> I (and my customer) am willing to put in some effort to make (or keep)
> gcc working for vxworks 5.

Sounds good, thanks.

Out of curiosity, what is your main motivation
for keeping upgrading the compiler version on such an environment ?

Do you have plans to move to a more recent version of VxWorks
at some point ?

> In case the ifdeffery in the existing
> vxworks-related files becomes too unwieldy, would it be possible to
> create a separate vxworks5 target, similar to the existing vxworksae
> variant?

A priori, I think we could do that as long as it's indeed similar
to the existing vxworksae variant in terms of amount/kind of alternate
sources and impact.

I don't think we should go as far as entirely insulating the
vx5 support.

We had an issue of the exact same kind when we worked on the
introduction of VxWorks7 support, and keeping things factorized helped
a lot on a number of accounts. I understand the situation we're
discussing is a bit different but most of the benefits remain valid
I think.

The changes you have so far look generally good (thanks again for
proposing them!) and it seems worth pursuing a bit in this direction. 

I hope the changes we have in the pipe won't make it harder. 

The vast majority are testsuite updates and ports to other
architectures. Otherwise, at a quick glance, a couple of fixincludes
related bits which we might even need to revisit before upstreaming,
and a minor libstdc++ configuration adjustment.

They were issued with at least up to vx6 still in mind and I
don't know of cases where we deliberately introduced something with
the conscious knowledge that it would break older configurations.
For sure, not in a fundamental impossible to recover fashion.

Olivier