[RFC PATCH 6/6] vxworks: don't define vxworks_asm_out_constructor when using .init_array

[RFC PATCH 6/6] vxworks: don't define vxworks_asm_out_constructor when using .init_array

[Rasmus Villemoes]

The definitions of TARGET_ASM_CONSTRUTOR in vxworks.h get undone in
initfini-array.h anyway when HAVE_INITFINI_ARRAY_SUPPORT, so we might as
well not define the functions.

2018-06-01  Rasmus Villemoes  <rasmus.villemoes@prevas.dk>

gcc/
	* config/vxworks.h: Guard vxworks_asm_out_constructor and
	  vxworks_asm_out_destructor by !HAVE_INITFINI_ARRAY_SUPPORT
	* config/vxworks.c: Likewise.
---
 gcc/config/vxworks.c | 2 ++
 gcc/config/vxworks.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/gcc/config/vxworks.c b/gcc/config/vxworks.c
index 953f74f71af..3b6b2343859 100644
--- a/gcc/config/vxworks.c
+++ b/gcc/config/vxworks.c
@@ -28,6 +28,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "output.h"
 #include "fold-const.h"
 
+#if !HAVE_INITFINI_ARRAY_SUPPORT
 /* Like default_named_section_asm_out_constructor, except that even
    constructors with DEFAULT_INIT_PRIORITY must go in a numbered
    section on VxWorks.  The VxWorks runtime uses a clever trick to get
@@ -56,6 +57,7 @@ vxworks_asm_out_destructor (rtx symbol, int priority)
 				    /*constructor_p=*/false);
   assemble_addr_to_section (symbol, sec);
 }
+#endif
 
 /* Return the list of FIELD_DECLs that make up an emulated TLS
    variable's control object.  TYPE is the structure these are fields
diff --git a/gcc/config/vxworks.h b/gcc/config/vxworks.h
index 58b89fbd5d2..cbb7d065ef0 100644
--- a/gcc/config/vxworks.h
+++ b/gcc/config/vxworks.h
@@ -149,6 +149,7 @@ extern void vxworks_override_options (void);
    appropriately.  */
 #define SUPPORTS_INIT_PRIORITY TARGET_VXWORKS_RTP || HAVE_INITFINI_ARRAY_SUPPORT
 
+#if !HAVE_INITFINI_ARRAY_SUPPORT
 /* VxWorks requires special handling of constructors and destructors.
    All VxWorks configurations must use these functions.  */
 #undef TARGET_ASM_CONSTRUCTOR
@@ -157,6 +158,7 @@ extern void vxworks_override_options (void);
 #define TARGET_ASM_DESTRUCTOR vxworks_asm_out_destructor
 extern void vxworks_asm_out_constructor (rtx symbol, int priority);
 extern void vxworks_asm_out_destructor (rtx symbol, int priority);
+#endif
 
 /* Override the vxworks-dummy.h definitions.  TARGET_VXWORKS_RTP
    is defined by vxworks.opt.  */
-- 
2.15.1

[RFC PATCH 1/6] vxworks: add target/h/wrn/coreip to the set of system include paths

[Rasmus Villemoes]

In order to build crtstuff.c, I need to ensure the headers in
target/h/wrn/coreip are also searched. Of course, that can be done
similar to how wrn/coreip gets manually added for libgcc, e.g. by adding

  CRTSTUFF_T_CFLAGS += -I$(WIND_BASE)/target/h -I$(WIND_BASE)/target/h/wrn/coreip

But without target/h/wrn/coreip in the default search path, all
user-code that include <unistd.h> (crtstuff.c just being one such
example) will have to manually add an -isystem
flag adding the wrn/coreip directory: unistd.h include ioLib.h, which
has

#include "net/uio.h"

and that header is found in target/h/wrn/coreip. In other words, the
VxWorks system headers (at least for VxWorks 5.5) are written in a way
that assumes wrn/coreip is in the search path, so I think it makes sense
to have that by default.

It will change the search order for existing setups that pass
-I.../target/h/wrn/coreip (without -nostdinc), since that flag will now
be ignored. I can't know whether that will break anything, but I do
believe it makes sense to have the defaults actually usable without
expecting all invocations to add -I/-isystem flags.

2018-06-04  Rasmus Villemoes  <rasmus.villemoes@prevas.dk>

gcc/

        * config/vxworks.h: Add $(WIND_BASE)/target/h/wrn/coreip to
          default search path.
---
 gcc/config/vxworks.h | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/gcc/config/vxworks.h b/gcc/config/vxworks.h
index e37af775157..08d2c9d76d6 100644
--- a/gcc/config/vxworks.h
+++ b/gcc/config/vxworks.h
@@ -61,9 +61,12 @@ along with GCC; see the file COPYING3.  If not see
 #undef VXWORKS_ADDITIONAL_CPP_SPEC
 #define VXWORKS_ADDITIONAL_CPP_SPEC		\
  "%{!nostdinc:					\
-    %{isystem*} -idirafter			\
-    %{mrtp: %:getenv(WIND_USR /h)		\
-      ;:    %:getenv(WIND_BASE /target/h)}}"
+    %{isystem*}					\
+    %{mrtp: -idirafter %:getenv(WIND_USR /h)	\
+	    -idirafter %:getenv(WIND_USR /h/wrn/coreip) \
+      ;:    -idirafter %:getenv(WIND_BASE /target/h) \
+	    -idirafter %:getenv(WIND_BASE /target/h/wrn/coreip) \
+}}"
 
 #endif
 
-- 
2.15.1

[RFC PATCH 0/6] some vxworks/powerpc patches

[Rasmus Villemoes]

These are some of the patches I'm currently applying to get a full C
and C++ compiler to work for powerpc-wrs-vxworks (for vxworks
5.5). With these, and a few more, I have ZCX, static
constuctors/destructors and throwing across modules working. There are
many vxworks variants out there, so I'm not sure how to avoid breaking
things for others. I don't really like the crti hack, but I don't have
any better ideas (I can probably patch the loader to recognize even
symbols of type unknown, but that won't benefit anybody else, so I'm
trying to fix problems in gcc whenever possible).

Rasmus Villemoes (6):
  vxworks: add target/h/wrn/coreip to the set of system include paths
  libgcc: add crt{begin,end} for powerpc-wrs-vxworks target
  vxworks: enable use of .init_array/.fini_array for cdtors
  powerpc/vxworks: [hack] add crti.o file
  powerpc/vxworks: add {START,END}FILE_SPEC for
    HAVE_INITFINI_ARRAY_SUPPORT
  vxworks: don't define vxworks_asm_out_constructor when using
    .init_array

 gcc/config/rs6000/vxworks.h         | 13 +++++++++++--
 gcc/config/vxworks.c                |  9 +++++++--
 gcc/config/vxworks.h                | 20 ++++++++++++++------
 libgcc/config.host                  |  3 ++-
 libgcc/config/rs6000/t-vxworks      |  5 +++++
 libgcc/config/rs6000/vxworks-crti.S | 10 ++++++++++
 6 files changed, 49 insertions(+), 11 deletions(-)
 create mode 100644 libgcc/config/rs6000/t-vxworks
 create mode 100644 libgcc/config/rs6000/vxworks-crti.S

-- 
2.15.1

[RFC PATCH 3/6] vxworks: enable use of .init_array/.fini_array for cdtors

[Rasmus Villemoes]

The target OS actually runs all function pointers found in the _ctors
array when the module is loaded. So it is not that hard to make use of
the "modern" .init_array/.fini_array mechanism - it mostly just requires
a linker script adding the _ctors and _dtors symbols and terminating
LONG(0) entries.

Assume that if the user passed --enable-initfini-array when building
gcc, the rest of the toolchain (including the linker script in use) is
set up appropriately.

2018-06-04  Rasmus Villemoes  <rasmus.villemoes@prevas.dk>

gcc/
	config/vxworks.c: Set targetm.have_ctors_dtors if HAVE_INITFINI_ARRAY_SUPPORT.
	config/vxworks.h: Set SUPPORTS_INIT_PRIORITY if HAVE_INITFINI_ARRAY_SUPPORT.
---
 gcc/config/vxworks.c | 7 +++++--
 gcc/config/vxworks.h | 9 ++++++---
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/gcc/config/vxworks.c b/gcc/config/vxworks.c
index 061f02057c2..953f74f71af 100644
--- a/gcc/config/vxworks.c
+++ b/gcc/config/vxworks.c
@@ -143,8 +143,11 @@ vxworks_override_options (void)
       targetm.emutls.debug_form_tls_address = true;
     }
 
-  /* We can use .ctors/.dtors sections only in RTP mode.  */
-  targetm.have_ctors_dtors = TARGET_VXWORKS_RTP;
+  /* We can use .ctors/.dtors sections only in RTP mode.  But, if the
+     compiler was built with --enable-initfini-array, assume the
+     toolchain implements the proper glue to make .init_array and
+     .fini_array work.  */
+  targetm.have_ctors_dtors = TARGET_VXWORKS_RTP || HAVE_INITFINI_ARRAY_SUPPORT;
 
   /* PIC is only supported for RTPs.  */
   if (flag_pic && !TARGET_VXWORKS_RTP)
diff --git a/gcc/config/vxworks.h b/gcc/config/vxworks.h
index 08d2c9d76d6..58b89fbd5d2 100644
--- a/gcc/config/vxworks.h
+++ b/gcc/config/vxworks.h
@@ -142,9 +142,12 @@ along with GCC; see the file COPYING3.  If not see
 #define VXWORKS_OVERRIDE_OPTIONS vxworks_override_options ()
 extern void vxworks_override_options (void);
 
-/* Only RTPs support prioritized constructors and destructors:
-   the implementation relies on numbered .ctors* sections.  */
-#define SUPPORTS_INIT_PRIORITY TARGET_VXWORKS_RTP
+/* RTPs support prioritized constructors and destructors: the
+   implementation relies on numbered .ctors* sections. If the compiler
+   was built with --enable-initfini-array, we assume the user uses a
+   linker script that sorts and merges the .init_array.* sections
+   appropriately.  */
+#define SUPPORTS_INIT_PRIORITY TARGET_VXWORKS_RTP || HAVE_INITFINI_ARRAY_SUPPORT
 
 /* VxWorks requires special handling of constructors and destructors.
    All VxWorks configurations must use these functions.  */
-- 
2.15.1

[RFC PATCH 5/6] powerpc/vxworks: add {START,END}FILE_SPEC for HAVE_INITFINI_ARRAY_SUPPORT

[Rasmus Villemoes]

VxWorks is a cross-compile target only, so if
HAVE_INITFINI_ARRAY_SUPPORT is defined, it is because gcc was explicitly
configured with --enable-initfini-array. So it is reasonable to expect
the user to use a linker script that implements the linker part of
this (namely, provide _ctors and _dtors symbols before the .init_array.*
and .init_array sections, and put a NULL terminator at the end).

I don't know anything about RTP (I'm targeting VxWorks 5, which doesn't
have those), so I'm avoiding touching the specs for that case.

There's nothing really ppc specific about this, but that happens to be
the target I have and can thus test on. Any other architecture should be
able to just copy the .S file and provide a similar crti.o, and then
this could be lifted to the target-agnostic vxworks.h header.

2018-06-01  Rasmus Villemoes  <rasmus.villemoes@prevas.dk>

gcc/

	* config/rs6000/vxworks.h: When --enable-initfini-array is used,
          add crtbegin.o and vxworks-crti.o to STARTFILE_SPEC and
          crtend.o to ENDFILE_SPEC.
---
 gcc/config/rs6000/vxworks.h | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/gcc/config/rs6000/vxworks.h b/gcc/config/rs6000/vxworks.h
index b10955f071d..7f0ac826e3c 100644
--- a/gcc/config/rs6000/vxworks.h
+++ b/gcc/config/rs6000/vxworks.h
@@ -90,10 +90,19 @@ VXWORKS_ADDITIONAL_CPP_SPEC
 #define LIB_SPEC VXWORKS_LIB_SPEC
 #undef  LINK_SPEC
 #define LINK_SPEC VXWORKS_LINK_SPEC
+
+#if HAVE_INITFINI_ARRAY_SUPPORT
+#define INIT_STARTFILE_SPEC "%{!mrtp:vxworks-crti.o%s crtbegin.o%s}"
+#define FINI_ENDFILE_SPEC "%{!mrtp:crtend.o%s}"
+#else
+#define INIT_STARTFILE_SPEC ""
+#define FINI_ENDFILE_SPEC ""
+#endif
+
 #undef  STARTFILE_SPEC
-#define STARTFILE_SPEC VXWORKS_STARTFILE_SPEC
+#define STARTFILE_SPEC VXWORKS_STARTFILE_SPEC INIT_STARTFILE_SPEC
 #undef  ENDFILE_SPEC
-#define ENDFILE_SPEC VXWORKS_ENDFILE_SPEC
+#define ENDFILE_SPEC VXWORKS_ENDFILE_SPEC FINI_ENDFILE_SPEC
 
 /* There is no default multilib.  */
 #undef MULTILIB_DEFAULTS
-- 
2.15.1

[RFC PATCH 4/6] powerpc/vxworks: [hack] add crti.o file

[Rasmus Villemoes]

The run-time linker on VxWorks almost supports the "modern"
.init_array/.fini_array way of dealing with static constructors and
destructors. On load of a module, it simply looks for a symbol _ctors
and expects that to be a NULL-terminated array of function pointers to
call (and similarly for _dtors on unload), and it does indeed call
_ctors in forward order and _dtors in reverse order. So all we need to
do is ensure the symbols _ctors and _dtors exist and arrange for a zero
terminator.

At first, I tried simply doing this in the linker script, i.e. something
like

PROVIDE(_ctors = .);
KEEP (*(SORT_BY_INIT_PRIORITY(.init_array.*)))
KEEP (*(.init_array))
LONG(0)

similar to the default linker scripts that just provide
__init_array_{start,end} symbols. Unfortunately, that is not quite
enough, since the _ctors symbol ends up with NOTYPE rather than OBJECT,
so it does not get recognized as a _ctors array by the VxWorks
runtime. I couldn't find a way to define the type of a linker-provided
symbol, so I'm resorting to this "hack".

I thought of also defining the symbol in the assembly file, but
then we'd have to put it in the .init_array.00000 section to also make
the _ctors array span static constructors with an init_priority. And
a corresponding crtn.o with a 0 entry would have to go in the
.init_array itself. I don't like that asymmetry between the crt{i,o}
files, and I think it's cleaner that the linker script defines both ends
of the array - this crti.o is merely a hack around my inability to
define the type of _ctors in the linker language.

2018-06-04  Rasmus Villemoes  <rasmus.villemoes@prevas.dk>

libgcc/

	* config.host: Add vxworks-crti.o to extra_parts for
          powerpc-wrs-vxworks.
	* config/rs6000/t-vxworks: New file.
	* config/rs6000/vxworks-crti.S: New file.
---
 libgcc/config.host                  |  4 ++--
 libgcc/config/rs6000/t-vxworks      |  5 +++++
 libgcc/config/rs6000/vxworks-crti.S | 10 ++++++++++
 3 files changed, 17 insertions(+), 2 deletions(-)
 create mode 100644 libgcc/config/rs6000/t-vxworks
 create mode 100644 libgcc/config/rs6000/vxworks-crti.S

diff --git a/libgcc/config.host b/libgcc/config.host
index b75c86bd4a6..a0da84647a6 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1111,8 +1111,8 @@ powerpc*-*-linux*)
 	md_unwind_header=rs6000/linux-unwind.h
 	;;
 powerpc-wrs-vxworks*)
-	tmake_file="$tmake_file rs6000/t-ppccomm rs6000/t-savresfgpr t-fdpbit"
-	extra_parts="$extra_parts crtbegin.o crtend.o"
+	tmake_file="$tmake_file rs6000/t-ppccomm rs6000/t-savresfgpr rs6000/t-vxworks t-fdpbit"
+	extra_parts="$extra_parts crtbegin.o crtend.o vxworks-crti.o"
 	;;
 powerpc-*-lynxos*)
 	tmake_file="$tmake_file rs6000/t-lynx t-fdpbit"
diff --git a/libgcc/config/rs6000/t-vxworks b/libgcc/config/rs6000/t-vxworks
new file mode 100644
index 00000000000..ab9bee121c9
--- /dev/null
+++ b/libgcc/config/rs6000/t-vxworks
@@ -0,0 +1,5 @@
+# We build crti.o, which serves to set the type of _ctors and _dtors
+# symbols to "object".
+
+vxworks-crti$(objext): $(srcdir)/config/rs6000/vxworks-crti.S
+	$(crt_compile) -c $<
diff --git a/libgcc/config/rs6000/vxworks-crti.S b/libgcc/config/rs6000/vxworks-crti.S
new file mode 100644
index 00000000000..14d571f8fa2
--- /dev/null
+++ b/libgcc/config/rs6000/vxworks-crti.S
@@ -0,0 +1,10 @@
+/* This file just ensures the global (linker-supplied) symbols _ctors
+   and _dtors get the appropriate type.  */
+
+	.ident	"GNU C vxworks-crti.o"
+
+	.globl _ctors
+	.type	_ctors, @object
+
+	.globl _dtors
+	.type	_dtors, @object
-- 
2.15.1

[RFC PATCH 2/6] libgcc: add crt{begin,end} for powerpc-wrs-vxworks target

[Rasmus Villemoes]

In order to allow ZCX on VxWorks, we need the frame_dummy function to do
the register_frame_info().

2018-06-04  Rasmus Villemoes  <rasmus.villemoes@prevas.dk>

libgcc/

        * config.host: Add crtbegin.o and crtend.o for
          powerpc-wrs-vxworks target.
---
 libgcc/config.host | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libgcc/config.host b/libgcc/config.host
index f8fd78279d3..b75c86bd4a6 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1112,6 +1112,7 @@ powerpc*-*-linux*)
 	;;
 powerpc-wrs-vxworks*)
 	tmake_file="$tmake_file rs6000/t-ppccomm rs6000/t-savresfgpr t-fdpbit"
+	extra_parts="$extra_parts crtbegin.o crtend.o"
 	;;
 powerpc-*-lynxos*)
 	tmake_file="$tmake_file rs6000/t-lynx t-fdpbit"
-- 
2.15.1

Re: [RFC PATCH 1/6] vxworks: add target/h/wrn/coreip to the set of system include paths

[Jeff Law]

On 06/04/2018 08:46 AM, Rasmus Villemoes wrote:
> In order to build crtstuff.c, I need to ensure the headers in
> target/h/wrn/coreip are also searched. Of course, that can be done
> similar to how wrn/coreip gets manually added for libgcc, e.g. by adding
> 
>   CRTSTUFF_T_CFLAGS += -I$(WIND_BASE)/target/h -I$(WIND_BASE)/target/h/wrn/coreip
> 
> But without target/h/wrn/coreip in the default search path, all
> user-code that include <unistd.h> (crtstuff.c just being one such
> example) will have to manually add an -isystem
> flag adding the wrn/coreip directory: unistd.h include ioLib.h, which
> has
> 
> #include "net/uio.h"
> 
> and that header is found in target/h/wrn/coreip. In other words, the
> VxWorks system headers (at least for VxWorks 5.5) are written in a way
> that assumes wrn/coreip is in the search path, so I think it makes sense
> to have that by default.
> 
> It will change the search order for existing setups that pass
> -I.../target/h/wrn/coreip (without -nostdinc), since that flag will now
> be ignored. I can't know whether that will break anything, but I do
> believe it makes sense to have the defaults actually usable without
> expecting all invocations to add -I/-isystem flags.
> 
> 2018-06-04  Rasmus Villemoes  <rasmus.villemoes@prevas.dk>
> 
> gcc/
> 
>         * config/vxworks.h: Add $(WIND_BASE)/target/h/wrn/coreip to
>           default search path.
I'm going to defer to Olivier on all 6 parts of this kit.  He knows
vxworks far better than I.

jeff

Re: [RFC PATCH 1/6] vxworks: add target/h/wrn/coreip to the set of system include paths

[Olivier Hainque]

> On 12 Jun 2018, at 23:12, Jeff Law <law@redhat.com> wrote:
> 
> I'm going to defer to Olivier on all 6 parts of this kit.  He knows
> vxworks far better than I.

No pb. I haven't forgotten about this :)

As I mentioned on another
thread,  exceptions on VxWorks is an intricate nest of
multiple parameters when you consider the possible variations
of kinds of modules you can make (RTP, DKMs, SKMs) combined
with different lines of VxWorks versions (6.7 introduced support
for dwarf eh for example), combined with the various context
in which a toolchain may be used (straight from a command line
or driven by the WindRiver IDEs).

This include path part alone looks sensible. I'd still like to
evaluate how it fares in a environment where many of there variations
are exercised, and I'm not quite done with this yet.

Olivier

Re: [RFC PATCH 1/6] vxworks: add target/h/wrn/coreip to the set of system include paths

[Rasmus Villemoes]

On 2018-06-12 23:34, Olivier Hainque wrote:
> 
> 
>> On 12 Jun 2018, at 23:12, Jeff Law <law@redhat.com> wrote:
>>
>> I'm going to defer to Olivier on all 6 parts of this kit.  He knows
>> vxworks far better than I.
> 
> No pb. I haven't forgotten about this :)
> 
> As I mentioned on another
> thread,  exceptions on VxWorks is an intricate nest of
> multiple parameters when you consider the possible variations
> of kinds of modules you can make (RTP, DKMs, SKMs) combined
> with different lines of VxWorks versions (6.7 introduced support
> for dwarf eh for example), combined with the various context
> in which a toolchain may be used (straight from a command line
> or driven by the WindRiver IDEs).
> 
> This include path part alone looks sensible. I'd still like to
> evaluate how it fares in a environment where many of there variations
> are exercised, and I'm not quite done with this yet.

Thanks, I do hope for careful scrutiny. As I said, I'm only working on a
VxWorks 5.5 powerpc target, and I obviously don't want to break stuff
for other settings, but I can't really test on other combinations than
the one I have. I try to break up the changes in small pieces, maybe
even smaller than one would usually do, to hopefully get the
uncontroversial parts upstream, and then we may just have to maintain
some patches in-house if there's no reasonable way to make it work for
everybody.

Rasmus

Re: [RFC PATCH 1/6] vxworks: add target/h/wrn/coreip to the set of system include paths

[Olivier Hainque]

Hi Rasmus,

> On 13 Jun 2018, at 08:46, Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote:
> 
>> This include path part alone looks sensible. I'd still like to
>> evaluate how it fares in a environment where many of there variations
>> are exercised, and I'm not quite done with this yet.
> 
> Thanks, I do hope for careful scrutiny.

:-)

> As I said, I'm only working on a
> VxWorks 5.5 powerpc target, and I obviously don't want to break stuff
> for other settings, but I can't really test on other combinations than
> the one I have.

> I try to break up the changes in small pieces, maybe
> even smaller than one would usually do, to hopefully get the
> uncontroversial parts upstream, and then we may just have to maintain
> some patches in-house if there's no reasonable way to make it work for
> everybody.

I noticed the effort and appreciate it, thanks.

This particular patch is fine. While I can commit it, I think
it would be nice to let you do it, assuming you will rapidly get
Write After Approval privileges (Thanks Jeff for the sponsoring !).

Still need to think about the other ones and experiment.

I don't think the crti trick will do, and I need to check
what happens for RTPs or SKMs with the rest, see how that
would/should[-not] interact with the mechanisms we have for
Ada, ...

Re: [RFC PATCH 0/6] some vxworks/powerpc patches

[Olivier Hainque]

Hi Rasmus,

> On 4 Jun 2018, at 16:46, Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote:
> 
> These are some of the patches I'm currently applying to get a full C
> and C++ compiler to work for powerpc-wrs-vxworks (for vxworks
> 5.5). With these, and a few more, I have ZCX, static
> constuctors/destructors and throwing across modules working. There are
> many vxworks variants out there, so I'm not sure how to avoid breaking
> things for others. I don't really like the crti hack, but I don't have
> any better ideas (I can probably patch the loader to recognize even
> symbols of type unknown, but that won't benefit anybody else, so I'm
> trying to fix problems in gcc whenever possible).
> 
> Rasmus Villemoes (6):

1/6:
>  vxworks: add target/h/wrn/coreip to the set of system include paths

As we discussed on the message dedicated to this patch, this
one is ok.

For the rest, I still have concerns for part of the patches. Some
would be ok modulo minor changes.

Before we get there: are you familiar with the "munch" facility
of VxWorks ?

That can offer alternatives to some of the things you were after.

3/6:
>  vxworks: enable use of .init_array/.fini_array for cdtors

Assuming we agree on the general approach, this part would
be fine modulo adding parens around the expression. It doesn't
do what you think it does in the current form.

I'm a bit worried that forcing .init_array for constructors
might not work for RTPs, at least on some versions of VxWorks.

We probably would need to fallback to ".ctors" as the section
base name for not so recent versions. I'm not clear on all the
ramifications there.

As long as we keep the patchset logic simple, that should not
be an issue, as we'll have only few things to adjust.

By keeping the logic simple, I mean restricting the effects
of --enable-initfini-array to a strict minimum in the toolchain
per se.

A bit like "issue ctors/dtors and .init_array/.fini_array
sections and assume the environment has the necessary support
to trigger the calls in priority order." and that's it.

Some of the crt related patches are too potentially damaging
for other modes of possible uses of a VxWorks toolchain, with
possibly other versions of VxWorks. 

I understand it works for you, that --enable-initfini-array is
a new mode of use and that users would have the choice of not
configuring with this.

I still think that we don't want to bind that configuration choice
to something too specific.

The more we enforce from that config choice, the trickier it will
get to be able to understand/explain what it means. The least we enforce,
the easier it will be to maintain and understand, and the more flexible
it will be for users.

I'll propose alternatives to the crt parts that I'd rather not get
in (below).

6/6:
>  vxworks: don't define vxworks_asm_out_constructor when using .init_array

Would be ok together with the previous one, and as long as we don't
uncover fallouts for RTPs (meaning, we might have to revisit this in the
future).

2/6:
>  libgcc: add crt{begin,end} for powerpc-wrs-vxworks target

That one would be fine as well. Even if we don't immediately add them
to link closures from the config files (see below), I see how handy it
can be to be able to reference them from user specs for instance.

4 and 5/6
>  powerpc/vxworks: add {START,END}FILE_SPEC for HAVE_INITFINI_ARRAY_SUPPORT
>  powerpc/vxworks: [hack] add crti.o file

I really think those two should stay out. As I mentioned in a previous message,
there are many possible uses of a toolchain and this (unconditional addition
of crtfiles and references to _ctors) would undoubtedly cause trouble in one
case or another.

Also, the reference to _ctors tie to strong assumptions about how the
environment arranges for .init_array to work, so really blurs the responsibility
assignments.

We might be able to come up with a proper set of options controlling what
crt file to include in such or such circumstance but we're not quite there yet.

In the meantime, I think you could get things to work with a custom
userland spec and local crti.o (or alike, on your end so you can name and
locate it as you wish).

You could have, for example a spec file like this (sketch, to give an idea):

*startfile:
+ vx_ctors-begin.o crtbegin.o%s

where vx_ctors-begin.c would hold something like:

  void (* volatile _ctors[])()
    __attribute__((section (".init_array"))) = {};

with possible adjustments to priority sections and synchronization
with your linker script.

You can handle the sentinel addition likewise, with a '*endfile'
spec, or leave this to your linker script.

Regards,

Olivier

Re: [RFC PATCH 0/6] some vxworks/powerpc patches

[Rasmus Villemoes]

On 2018-06-19 18:45, Olivier Hainque wrote:
> Hi Rasmus,
> 
> 
> 1/6:
>>  vxworks: add target/h/wrn/coreip to the set of system include paths
> 
> As we discussed on the message dedicated to this patch, this
> one is ok.
> 
> For the rest, I still have concerns for part of the patches. Some
> would be ok modulo minor changes.
> 
> Before we get there: are you familiar with the "munch" facility
> of VxWorks ?
> 
> That can offer alternatives to some of the things you were after.

Yes, but doing regexp match on nm output feels wrong (though I am aware
that that is how things have been done for decades), and I really prefer
using the modern methods, which also allows e.g. use of constructor
priorities.

> 3/6:
>>  vxworks: enable use of .init_array/.fini_array for cdtors
> 
> Assuming we agree on the general approach, this part would
> be fine modulo adding parens around the expression. It doesn't
> do what you think it does in the current form.

Ah, of course. I'll add parens for the next roll.

> I'm a bit worried that forcing .init_array for constructors
> might not work for RTPs, at least on some versions of VxWorks.
> 
> We probably would need to fallback to ".ctors" as the section
> base name for not so recent versions. I'm not clear on all the
> ramifications there.

Hm, but if somebody built a compiler with --enable-initfini-array today
and passed -mrtp to it, they would already get .init_array instead of
.ctors, no? I.e., initfini-array.h would be included by tm.h after
vxworks.h, and the logic there would unconditionally override
vxworks.h's setting of TARGET_ASM_CONSTRUCTOR. So this "forcing" seems
to happen already for such a compiler, regardless of my patch?

> Some of the crt related patches are too potentially damaging
> for other modes of possible uses of a VxWorks toolchain, with
> possibly other versions of VxWorks. 

OK.

> I understand it works for you, that --enable-initfini-array is
> a new mode of use and that users would have the choice of not
> configuring with this.
> 
> I still think that we don't want to bind that configuration choice
> to something too specific.

OK.

> The more we enforce from that config choice, the trickier it will
> get to be able to understand/explain what it means. The least we enforce,
> the easier it will be to maintain and understand, and the more flexible
> it will be for users.
> 
> I'll propose alternatives to the crt parts that I'd rather not get
> in (below).
> 
> 6/6:
>>  vxworks: don't define vxworks_asm_out_constructor when using .init_array
> 
> Would be ok together with the previous one, and as long as we don't
> uncover fallouts for RTPs (meaning, we might have to revisit this in the
> future).

See above, I don't see how that could happen. Patch 6/6 is essentially a
no-op, except that it makes the compiler binary a tiny bit smaller.

> 2/6:
>>  libgcc: add crt{begin,end} for powerpc-wrs-vxworks target
> 
> That one would be fine as well. Even if we don't immediately add them
> to link closures from the config files (see below), I see how handy it
> can be to be able to reference them from user specs for instance.

Yes, I hope that building and installing crtbegin/end should be
harmless; it just requires that crtstuff.c actually compiles cleanly.

> 4 and 5/6
>>  powerpc/vxworks: add {START,END}FILE_SPEC for HAVE_INITFINI_ARRAY_SUPPORT
>>  powerpc/vxworks: [hack] add crti.o file
> 
> I really think those two should stay out. As I mentioned in a previous message,
> there are many possible uses of a toolchain and this (unconditional addition
> of crtfiles and references to _ctors) would undoubtedly cause trouble in one
> case or another.
> 
> Also, the reference to _ctors tie to strong assumptions about how the
> environment arranges for .init_array to work, so really blurs the responsibility
> assignments.
> 
> We might be able to come up with a proper set of options controlling what
> crt file to include in such or such circumstance but we're not quite there yet.
> 
> In the meantime, I think you could get things to work with a custom
> userland spec and local crti.o (or alike, on your end so you can name and
> locate it as you wish).

Yes, these two are the most hackish ones, and I don't much like them
myself. So I'm happy to leave them out of mainline, and just use them
(or something equivalent) in-house.

> You could have, for example a spec file like this (sketch, to give an idea):
> 
> *startfile:
> + vx_ctors-begin.o crtbegin.o%s
> 
> where vx_ctors-begin.c would hold something like:
> 
>   void (* volatile _ctors[])()
>     __attribute__((section (".init_array"))) = {};
> 
> with possible adjustments to priority sections and synchronization
> with your linker script.
> 
> You can handle the sentinel addition likewise, with a '*endfile'
> spec, or leave this to your linker script.

Using a custom spec file, custom linker script and something like the
vx_ctors_begin.o will probably be the long-term solution for us. We'd be
really happy to be able to use an upstream gcc out-of-the-box apart from
those few pieces of glue.

I'll fix and resend 1,2,3,6.

Once again, thank you for you time, Olivier!

Rasmus

Re: [RFC PATCH 0/6] some vxworks/powerpc patches

[Olivier Hainque]

Hello Rasmus,

> On 26 Jun 2018, at 14:45, Rasmus Villemoes <rasmus.villemoes@prevas.dk> wrote:
> 
> On 2018-06-19 18:45, Olivier Hainque wrote:
>> 
>> Before we get there: are you familiar with the "munch" facility
>> of VxWorks ?
> 
> Yes, but doing regexp match on nm output feels wrong (though I am aware
> that that is how things have been done for decades), and I really prefer
> using the modern methods, which also allows e.g. use of constructor
> priorities.

I agree the perspective of having an alternate mechanism is
attractive :)

>> I'm a bit worried that forcing .init_array for constructors
>> might not work for RTPs, at least on some versions of VxWorks.
>> 
>> We probably would need to fallback to ".ctors" as the section
>> base name for not so recent versions. I'm not clear on all the
>> ramifications there.
> 
> Hm, but if somebody built a compiler with --enable-initfini-array today
> and passed -mrtp to it, they would already get .init_array instead of
> .ctors, no? I.e., initfini-array.h would be included by tm.h after
> vxworks.h, and the logic there would unconditionally override
> vxworks.h's setting of TARGET_ASM_CONSTRUCTOR. So this "forcing" seems
> to happen already for such a compiler, regardless of my patch?

Right. It's just that there is no trace of init-fini support
before the patch, so it is not really expected to work. The
presence of conditions on HAVE_INITFINI_ARRAY here and there sends
a pretty strong signal that --enable-initfini-array is expected
to do something sensible, and obviously breaking RTPs would be
annoying.

Now the patches we're discussing (without 4 and 5) are non-intrusive
enough to allow a quick understanding and simple definition of the effects,
and it's not clear that RTPs would indeed be broken to this is not
blocking at this stage.

This can be seen as a step forward which maybe will call for adjustments
for RTPs.

>> 6/6:
>>> vxworks: don't define vxworks_asm_out_constructor when using .init_array
>> 
>> Would be ok together with the previous one, and as long as we don't
>> uncover fallouts for RTPs (meaning, we might have to revisit this in the
>> future).
> 
> See above, I don't see how that could happen. Patch 6/6 is essentially a
> no-op, except that it makes the compiler binary a tiny bit smaller.

In the current state, I agree. Experiments on RTPs might show a need
for adjustments but we're not there and it's fine to defer this part.

>> 2/6:
>>> libgcc: add crt{begin,end} for powerpc-wrs-vxworks target
>> 
>> That one would be fine as well. Even if we don't immediately add them
>> to link closures from the config files (see below), I see how handy it
>> can be to be able to reference them from user specs for instance.
> 
> Yes, I hope that building and installing crtbegin/end should be
> harmless; it just requires that crtstuff.c actually compiles cleanly.
> 
>> 4 and 5/6
>>> powerpc/vxworks: add {START,END}FILE_SPEC for HAVE_INITFINI_ARRAY_SUPPORT
>>> powerpc/vxworks: [hack] add crti.o file
>> 
>> I really think those two should stay out.

> Yes, these two are the most hackish ones, and I don't much like them
> myself. So I'm happy to leave them out of mainline, and just use them
> (or something equivalent) in-house.

Ok, glad we agree on this.

> Using a custom spec file, custom linker script and something like the
> vx_ctors_begin.o will probably be the long-term solution for us. We'd be
> really happy to be able to use an upstream gcc out-of-the-box apart from
> those few pieces of glue.
> 
> I'll fix and resend 1,2,3,6.

Works for me. I won't be able to review for 3+ weeks.

> Once again, thank you for you time, Olivier!

Sure. Thanks for your proposing the approach and input
on how it works for you. This is an interesting way to address
a pretty hairy issue.

Regards,

Olivier

[PATCH v2 2/4] libgcc: add crt{begin,end} for powerpc-wrs-vxworks target

[Rasmus Villemoes]

In order to allow ZCX on VxWorks, we need the frame_dummy function to do
the register_frame_info(). So make sure crtbegin.o and crtend.o are
available for use with a custom spec file.

2018-06-04  Rasmus Villemoes  <rv@rasmusvillemoes.dk>

libgcc/

        * config.host: Add crtbegin.o and crtend.o for
          powerpc-wrs-vxworks target.
---
 libgcc/config.host | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libgcc/config.host b/libgcc/config.host
index 18cabaf24f6..3466ba70f27 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -1129,6 +1129,7 @@ powerpc*-*-linux*)
 	;;
 powerpc-wrs-vxworks*)
 	tmake_file="$tmake_file rs6000/t-ppccomm rs6000/t-savresfgpr t-fdpbit"
+	extra_parts="$extra_parts crtbegin.o crtend.o"
 	;;
 powerpc-*-lynxos*)
 	tmake_file="$tmake_file rs6000/t-lynx t-fdpbit"
-- 
2.16.4

[PATCH v2 3/4] vxworks: enable use of .init_array/.fini_array for cdtors

[Rasmus Villemoes]

The target OS actually runs all function pointers found in the _ctors
array when the module is loaded. So it is not that hard to make use of
the "modern" .init_array/.fini_array mechanism - it mostly just requires
a linker script adding the _ctors and _dtors symbols and terminating
LONG(0) entries.

Assume that if the user passed --enable-initfini-array when building
gcc, the rest of the toolchain (including the link spec and linker
script) is set up appropriately.

Note that configuring with --enable-initfini-array may prevent the -mrtp
mode from working, due to the (unconditional) use of .init_array.*
sections instead of .ctors.* - however, that is the case regardless of this
patch.

2018-06-04  Rasmus Villemoes  <rv@rasmusvillemoes.dk>

gcc/
	config/vxworks.c: Set targetm.have_ctors_dtors if HAVE_INITFINI_ARRAY_SUPPORT.
	config/vxworks.h: Set SUPPORTS_INIT_PRIORITY if HAVE_INITFINI_ARRAY_SUPPORT.
---
 gcc/config/vxworks.c |  7 +++++--
 gcc/config/vxworks.h | 10 +++++++---
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/gcc/config/vxworks.c b/gcc/config/vxworks.c
index 061f02057c2..953f74f71af 100644
--- a/gcc/config/vxworks.c
+++ b/gcc/config/vxworks.c
@@ -143,8 +143,11 @@ vxworks_override_options (void)
       targetm.emutls.debug_form_tls_address = true;
     }
 
-  /* We can use .ctors/.dtors sections only in RTP mode.  */
-  targetm.have_ctors_dtors = TARGET_VXWORKS_RTP;
+  /* We can use .ctors/.dtors sections only in RTP mode.  But, if the
+     compiler was built with --enable-initfini-array, assume the
+     toolchain implements the proper glue to make .init_array and
+     .fini_array work.  */
+  targetm.have_ctors_dtors = TARGET_VXWORKS_RTP || HAVE_INITFINI_ARRAY_SUPPORT;
 
   /* PIC is only supported for RTPs.  */
   if (flag_pic && !TARGET_VXWORKS_RTP)
diff --git a/gcc/config/vxworks.h b/gcc/config/vxworks.h
index 08d2c9d76d6..4c2d98381f6 100644
--- a/gcc/config/vxworks.h
+++ b/gcc/config/vxworks.h
@@ -142,9 +142,13 @@ along with GCC; see the file COPYING3.  If not see
 #define VXWORKS_OVERRIDE_OPTIONS vxworks_override_options ()
 extern void vxworks_override_options (void);
 
-/* Only RTPs support prioritized constructors and destructors:
-   the implementation relies on numbered .ctors* sections.  */
-#define SUPPORTS_INIT_PRIORITY TARGET_VXWORKS_RTP
+/* RTPs support prioritized constructors and destructors: the
+   implementation relies on numbered .ctors* sections. If the compiler
+   was built with --enable-initfini-array, we assume the user uses a
+   linker script that sorts and merges the .init_array.* sections
+   appropriately.  */
+#define SUPPORTS_INIT_PRIORITY \
+  (TARGET_VXWORKS_RTP || HAVE_INITFINI_ARRAY_SUPPORT)
 
 /* VxWorks requires special handling of constructors and destructors.
    All VxWorks configurations must use these functions.  */
-- 
2.16.4

[PATCH v2 4/4] vxworks: don't define vxworks_asm_out_constructor when using .init_array

[Rasmus Villemoes]

When the compiler is configured with --enable-initfini-array,
config/initfini-array.h gets included after config/vxworks.h by tm.h, so
the definitions of TARGET_ASM_CONSTRUTOR/TARGET_ASM_DESTRUCTOR in
vxworks.h get undone in initfini-array.h. Hence, we might as well not
define the vxworks_asm_out_* functions.

2018-06-01  Rasmus Villemoes  <rv@rasmusvillemoes.dk>

gcc/
	* config/vxworks.h: Guard vxworks_asm_out_constructor and
	  vxworks_asm_out_destructor by !HAVE_INITFINI_ARRAY_SUPPORT
	* config/vxworks.c: Likewise.
---
 gcc/config/vxworks.c | 2 ++
 gcc/config/vxworks.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/gcc/config/vxworks.c b/gcc/config/vxworks.c
index 953f74f71af..3b6b2343859 100644
--- a/gcc/config/vxworks.c
+++ b/gcc/config/vxworks.c
@@ -28,6 +28,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "output.h"
 #include "fold-const.h"
 
+#if !HAVE_INITFINI_ARRAY_SUPPORT
 /* Like default_named_section_asm_out_constructor, except that even
    constructors with DEFAULT_INIT_PRIORITY must go in a numbered
    section on VxWorks.  The VxWorks runtime uses a clever trick to get
@@ -56,6 +57,7 @@ vxworks_asm_out_destructor (rtx symbol, int priority)
 				    /*constructor_p=*/false);
   assemble_addr_to_section (symbol, sec);
 }
+#endif
 
 /* Return the list of FIELD_DECLs that make up an emulated TLS
    variable's control object.  TYPE is the structure these are fields
diff --git a/gcc/config/vxworks.h b/gcc/config/vxworks.h
index 4c2d98381f6..86773868ec2 100644
--- a/gcc/config/vxworks.h
+++ b/gcc/config/vxworks.h
@@ -150,6 +150,7 @@ extern void vxworks_override_options (void);
 #define SUPPORTS_INIT_PRIORITY \
   (TARGET_VXWORKS_RTP || HAVE_INITFINI_ARRAY_SUPPORT)
 
+#if !HAVE_INITFINI_ARRAY_SUPPORT
 /* VxWorks requires special handling of constructors and destructors.
    All VxWorks configurations must use these functions.  */
 #undef TARGET_ASM_CONSTRUCTOR
@@ -158,6 +159,7 @@ extern void vxworks_override_options (void);
 #define TARGET_ASM_DESTRUCTOR vxworks_asm_out_destructor
 extern void vxworks_asm_out_constructor (rtx symbol, int priority);
 extern void vxworks_asm_out_destructor (rtx symbol, int priority);
+#endif
 
 /* Override the vxworks-dummy.h definitions.  TARGET_VXWORKS_RTP
    is defined by vxworks.opt.  */
-- 
2.16.4

[PATCH v2 1/4] vxworks: add target/h/wrn/coreip to the set of system include paths

[Rasmus Villemoes]

In order to build crtstuff.c, I need to ensure the headers in
target/h/wrn/coreip are also searched. Of course, that can be done
similar to how wrn/coreip gets manually added for libgcc, e.g. by adding

  CRTSTUFF_T_CFLAGS += -I$(WIND_BASE)/target/h -I$(WIND_BASE)/target/h/wrn/coreip

But without target/h/wrn/coreip in the default search path, all
user-code that include <unistd.h> (crtstuff.c just being one such
example) will have to manually add an -isystem
flag adding the wrn/coreip directory: unistd.h include ioLib.h, which
has

#include "net/uio.h"

and that header is found in target/h/wrn/coreip. In other words, the
VxWorks system headers (at least for VxWorks 5.5) are written in a way
that assumes wrn/coreip is in the search path, so I think it makes sense
to have that by default.

It will change the search order for existing setups that pass
-I.../target/h/wrn/coreip (without -nostdinc), since that flag will now
be ignored. I can't know whether that will break anything, but I do
believe it makes sense to have the defaults actually usable without
expecting all invocations to add -I/-isystem flags.

2018-06-04  Rasmus Villemoes  <rv@rasmusvillemoes.dk>

gcc/

        * config/vxworks.h: Add $(WIND_BASE)/target/h/wrn/coreip to
          default search path.
---
 gcc/config/vxworks.h | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/gcc/config/vxworks.h b/gcc/config/vxworks.h
index e37af775157..08d2c9d76d6 100644
--- a/gcc/config/vxworks.h
+++ b/gcc/config/vxworks.h
@@ -61,9 +61,12 @@ along with GCC; see the file COPYING3.  If not see
 #undef VXWORKS_ADDITIONAL_CPP_SPEC
 #define VXWORKS_ADDITIONAL_CPP_SPEC		\
  "%{!nostdinc:					\
-    %{isystem*} -idirafter			\
-    %{mrtp: %:getenv(WIND_USR /h)		\
-      ;:    %:getenv(WIND_BASE /target/h)}}"
+    %{isystem*}					\
+    %{mrtp: -idirafter %:getenv(WIND_USR /h)	\
+	    -idirafter %:getenv(WIND_USR /h/wrn/coreip) \
+      ;:    -idirafter %:getenv(WIND_BASE /target/h) \
+	    -idirafter %:getenv(WIND_BASE /target/h/wrn/coreip) \
+}}"
 
 #endif
 
-- 
2.16.4

[PATCH v2 0/4] some vxworks/powerpc patches

[Rasmus Villemoes]

Patches 1, 2 and 4 (the latter was number 6 previously) are unchanged
from the first round, apart from small changes in the commit log
wording. Patch 3 now includes parentheses in the macro
definition. Patches 4 and 5 are dropped.

4/4 is mostly a minor optimization, omitting a tiny bit of dead code
from the compiler binary. But the preprocessor directives also serve
as a reminder that the custom vxworks functions will not be used if
the compiler is built with --enable-initfini-array.

Rasmus Villemoes (4):
  vxworks: add target/h/wrn/coreip to the set of system include paths
  libgcc: add crt{begin,end} for powerpc-wrs-vxworks target
  vxworks: enable use of .init_array/.fini_array for cdtors
  vxworks: don't define vxworks_asm_out_constructor when using
    .init_array

 gcc/config/vxworks.c |  9 +++++++--
 gcc/config/vxworks.h | 21 +++++++++++++++------
 libgcc/config.host   |  1 +
 3 files changed, 23 insertions(+), 8 deletions(-)

-- 
2.16.4

Re: [PATCH v2 0/4] some vxworks/powerpc patches

[Olivier Hainque]

Hello Rasmus,

(Back after a summer break & some backlog preemption)

Thanks for resubmitting those patches. 

Re reviewing; will get back to you when I'm done,
hopefully soon :)

Olivier

> On 28 Jun 2018, at 10:43, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
> 
> Patches 1, 2 and 4 (the latter was number 6 previously) are unchanged
> from the first round, apart from small changes in the commit log
> wording. Patch 3 now includes parentheses in the macro
> definition. Patches 4 and 5 are dropped.
> 
> 4/4 is mostly a minor optimization, omitting a tiny bit of dead code
> from the compiler binary. But the preprocessor directives also serve
> as a reminder that the custom vxworks functions will not be used if
> the compiler is built with --enable-initfini-array.
> 
> Rasmus Villemoes (4):
>  vxworks: add target/h/wrn/coreip to the set of system include paths
>  libgcc: add crt{begin,end} for powerpc-wrs-vxworks target
>  vxworks: enable use of .init_array/.fini_array for cdtors
>  vxworks: don't define vxworks_asm_out_constructor when using
>    .init_array
> 
> gcc/config/vxworks.c |  9 +++++++--
> gcc/config/vxworks.h | 21 +++++++++++++++------
> libgcc/config.host   |  1 +
> 3 files changed, 23 insertions(+), 8 deletions(-)
> 
> -- 
> 2.16.4
> 

Re: [PATCH v2 1/4] vxworks: add target/h/wrn/coreip to the set of system include paths

[Olivier Hainque]

Hi Rasmus,

> On 28 Jun 2018, at 10:43, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
> 
> 2018-06-04  Rasmus Villemoes  <rv@rasmusvillemoes.dk>
> 
>        * config/vxworks.h: Add $(WIND_BASE)/target/h/wrn/coreip to
>          default search path.

Ok, thanks.

Olivier

Re: [PATCH v2 1/4] vxworks: add target/h/wrn/coreip to the set of system include paths

[Olivier Hainque]

> On 6 Aug 2018, at 14:12, Olivier Hainque <hainque@adacore.com> wrote:
>>       * config/vxworks.h: Add $(WIND_BASE)/target/h/wrn/coreip to
>>         default search path.
> 
> Ok, thanks.

With a nit on the ChangeLog formatting:

	* config/vxworks.h: Add $(WIND_BASE)/target/h/wrn/coreip to
	default search path.

	^
	no extra space here

and an indication that this is for VxWorks pre vx7.

Thanks.

Olivier

Re: [PATCH v2 3/4] vxworks: enable use of .init_array/.fini_array for cdtors

[Olivier Hainque]

Hello Rasmus,

> On 28 Jun 2018, at 10:43, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
> 
> Assume that if the user passed --enable-initfini-array when building
> gcc, the rest of the toolchain (including the link spec and linker
> script) is set up appropriately.
> 
> Note that configuring with --enable-initfini-array may prevent the -mrtp
> mode from working,

> due to the (unconditional) use of .init_array.*
> sections instead of .ctors.* -

Just spent some time verifying this, and, indeed getting
a RTP to work with this setup is going to be tough, if at
all possible.

> however, that is the case regardless of this patch.

Right, though the situation becomes a bit different
with the patch as we now have references to the macro,
sort of implying it should work.

I still think it's fine, as what we do is simply honor
what the doc of --enable-initfini-array states: generate
constructor/desctructors in init/fini_array sections,
nothing more, and the comments pretty clearly state that
it's the responsibility of the one who configured this
way to manage the constructors and fit them into the OS
runtime.

And we can revisit if we find a better way out.

So, as it allows at least a use case to operate smoothly
...

> 2018-06-04  Rasmus Villemoes  <rv@rasmusvillemoes.dk>
> 
> gcc/
> 	config/vxworks.c: Set targetm.have_ctors_dtors if HAVE_INITFINI_ARRAY_SUPPORT.
>  config/vxworks.h: Set SUPPORTS_INIT_PRIORITY if HAVE_INITFINI_ARRAY_SUPPORT.

Ok, modulo ChangeLog reformatting:

	* config/vxworks.c: Set targetm.have_ctors_dtors if
	HAVE_INITFINI_ARRAY_SUPPORT.
	* config/vxworks.h: Set SUPPORTS_INIT_PRIORITY if
	HAVE_INITFINI_ARRAY_SUPPORT.

Thanks,

Olivier

Re: [PATCH v2 3/4] vxworks: enable use of .init_array/.fini_array for cdtors

[Rasmus Villemoes]

On 2018-08-10 17:59, Olivier Hainque wrote:
> Hello Rasmus,
> 
>> On 28 Jun 2018, at 10:43, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
>>
>> Assume that if the user passed --enable-initfini-array when building
>> gcc, the rest of the toolchain (including the link spec and linker
>> script) is set up appropriately.
>> 2018-06-04  Rasmus Villemoes  <rv@rasmusvillemoes.dk>
>>
>> gcc/
>> 	config/vxworks.c: Set targetm.have_ctors_dtors if HAVE_INITFINI_ARRAY_SUPPORT.
>>  config/vxworks.h: Set SUPPORTS_INIT_PRIORITY if HAVE_INITFINI_ARRAY_SUPPORT.
> 
> Ok, modulo ChangeLog reformatting:
> 
> 	* config/vxworks.c: Set targetm.have_ctors_dtors if
> 	HAVE_INITFINI_ARRAY_SUPPORT.
> 	* config/vxworks.h: Set SUPPORTS_INIT_PRIORITY if
> 	HAVE_INITFINI_ARRAY_SUPPORT.

Thanks for spotting that. I have a script that fixes the whitespace
issue automatically, but it doesn't catch missing leading * in entries.

Do you want me to send an updated and rebased version of these patches
(including changelog fixups)?

Thanks,
Rasmus

Re: [PATCH v2 3/4] vxworks: enable use of .init_array/.fini_array for cdtors

[Olivier Hainque]

Hi Rasmus,

> On 13 Aug 2018, at 10:24, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
> 
>> Ok, modulo ChangeLog reformatting:
> 
> Thanks for spotting that. I have a script that fixes the whitespace
> issue automatically, but it doesn't catch missing leading * in entries.
> 
> Do you want me to send an updated and rebased version of these patches
> (including changelog fixups)?

No, no need to repost just for the ChangeLog
format update.

Thanks,

Olivier

Re: [PATCH v2 4/4] vxworks: don't define vxworks_asm_out_constructor when using .init_array

[Olivier Hainque]

Hello Rasmus,

> On 28 Jun 2018, at 10:43, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
> 
> 	* config/vxworks.h: Guard vxworks_asm_out_constructor and
> 	  vxworks_asm_out_destructor by !HAVE_INITFINI_ARRAY_SUPPORT
> 	* config/vxworks.c: Likewise.

ok as well, also modulo a ChangeLog formatting nit: log continuations
beyond the first line start below the '*' of the first line, so:

	* config/vxworks.h: Guard vxworks_asm_out_constructor and
	vxworks_asm_out_destructor by !HAVE_INITFINI_ARRAY_SUPPORT.

Thanks,

Olivier

Re: [PATCH v2 2/4] libgcc: add crt{begin,end} for powerpc-wrs-vxworks target

[Rasmus Villemoes]

On 2018-06-28 10:43, Rasmus Villemoes wrote:
> In order to allow ZCX on VxWorks, we need the frame_dummy function to do
> the register_frame_info(). So make sure crtbegin.o and crtend.o are
> available for use with a custom spec file.

Hi Olivier

Can I also have your explicit ok for patch 2/4 (I'll fix the changelog
as for the other patches)?

Thanks,
Rasmus

Re: [PATCH v2 2/4] libgcc: add crt{begin,end} for powerpc-wrs-vxworks target

[Olivier Hainque]

Hi Rasmus,

> On 16 Aug 2018, at 11:30, Rasmus Villemoes <rv@rasmusvillemoes.dk> wrote:
> 
> On 2018-06-28 10:43, Rasmus Villemoes wrote:
>> In order to allow ZCX on VxWorks, we need the frame_dummy function to do
>> the register_frame_info(). So make sure crtbegin.o and crtend.o are
>> available for use with a custom spec file.
> 
> Hi Olivier
> 
> Can I also have your explicit ok for patch 2/4 (I'll fix the changelog
> as for the other patches)?

Yes, this is fine.

We're working on a possible replacement of those crt
files for VxWorks. Just not quite ready yet and no reason
to block the current ones in the interim.

Olivier