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

Message ID 20180604144626.5902-2-rasmus.villemoes@prevas.dk
State New
Headers show
Series
  • some vxworks/powerpc patches
Related show

Commit Message

Rasmus Villemoes June 4, 2018, 2:46 p.m.
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(-)

-- 
2.15.1

Comments

Jeff Law June 12, 2018, 9:12 p.m. | #1
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
Olivier Hainque June 12, 2018, 9:34 p.m. | #2
> 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
Rasmus Villemoes June 13, 2018, 6:46 a.m. | #3
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
Olivier Hainque June 14, 2018, 8:40 a.m. | #4
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, ...

Patch

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