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

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

[Olivier Hainque]

Hi Rasmus,

(switched from gcc to gcc-patches list)

> On 26 May 2020, at 16:52, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
> 
> 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);

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

Ok (with a ChangeLog),

Thanks,

Olivier

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

[Olivier Hainque]

Hi Rasmus,

> On 26 May 2020, at 16:52, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
> 
> 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.

This one is OK for me, with a ChangeLog please. Thanks.

Olivier

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

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

[Olivier Hainque]

Hi Rasmus,

> On 26 May 2020, at 16:52, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
> 
> As for __GTHREAD_HAS_COND, use __GTHREAD_CXX0X to guard the actual
> contents of gthr-vxworks-thread.c.

Good for me.
 
> That should also allow dropping the
> t-gthr-vxworksae fragment and simply use t-gthr-vxworks.

Indeed. 

Thanks.

Olivier