| Message ID | 20180604144626.5902-2-rasmus.villemoes@prevas.dk |
|---|---|
| State | New |
| Headers | show |
| Series | some vxworks/powerpc patches | expand |
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
> 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
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
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, ...
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
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(-)