> On 13 Sep 2018, at 00:25, Rasmus Villemoes <r...@rasmusvillemoes.dk> wrote:
>> What happens on your end if you just remove the hack ?
> Unfortunately, the libstdc++ build breaks:
>
> In file included from
> /usr/powerpc-wrs-vxworks/wind_base/target/h/regs.h:66:0,
> from
> /bld/vestas/auto/work.20180912.214646/gcc-build/gcc/include-fixed/setjmp.h:57,
> from
> /bld/vestas/auto/work.20180912.214646/gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include/csetjmp:42,
> from
> /bld/vestas/auto/work.20180912.214646/gcc-src/libstdc++-v3/include/precompiled/stdc++.h:42:
> /usr/powerpc-wrs-vxworks/wind_base/target/h/arch/ppc/regsPpc.h:33:5:
> error: 'UINT32' does not name a type
> UINT32 cr; /* condition register */
> ^~~~~~
Ah, I see. Thanks for the experiment.
> I'm happy to add an include of vxCpu in the _ASMLANGUAGE case, along
> with a big comment. But, it's also a small enough patch that we can
> carry it internally, if you prefer that we don't touch this hack upstream.
I'm fine with a change here. It could only possibly impact inclusions
of regs.h from assembly, and should normally improve that, so the risk
of breaking something is very low.
We can always reassess if need be. We (AdaCore) have managed to work
without fixincludes so far but will probably need to start relying on
it in the near future. This will shake it some more.
I wonder how we haven't hit the stop above, as it indicates an
inclusion of regs.h without a prior inclusion of vxTypes from the
VxWorks setjmp.h, included unconditionally from precompiled/stdc++.h
via csetjmp. Maybe different set of headers for different versions
of the OS.
A comment would help and doesn't need to be big.
The general idea, I think, is that different pieces of regs.h are
useful in assembly or other contexts, the two contexts rely on slightly
different sets of prerequisites and the more complete set (vxTypesOld.h)
is incompatible with an inclusion in assembly for some configurations.
Olivier
