Hi Rasmus, > On 3 Sep 2018, at 15:20, Rasmus Villemoes <r...@rasmusvillemoes.dk> wrote:
>> How do we not get in assembly the problems we'd get in C >> when not including vxTypesOld ? Answering part of my own question: turns out that some pieces included via regs.h are already taking care of the _ASMLANGUAGE case. > Well, I don't know why types/vxTypesOld.h got shoehorned into the > fixinclude regs.h [1]. A better fix would be to remove that #include > completely, making the fixinclude regs.h a pure wrapper for vxworks > regs.h. However, I was afraid that might break existing C code that has > come to rely on "#include <regs.h>" pulling in types/vxTypesOld.h (or > any of the headers included from that), and it's not really possible to > know if such code exists - other than trying it and waiting for emails > to arrive.(*) > As I wrote, including the vxworks regs.h (from assembly or C) requires > that types/vxCpu.h is already included, because it contains directives > such as > > #if CPU_FAMILY==I960 > ... > #if CPU_FAMILY==MC680X0 > Hence my "fix" relies on the fact that any existing assembly source that > includes regs.h must already have arranged for types/vxCpu.h to be > included, one way or another. I could add an explicit include of that > (maybe just in the _ASMLANGUAGE case), but that could easily cause > problems of its own. Now, if one could rely on all existing C code > having been through a non-gcc compiler, the same argument could be > applied and my above worry (*) would be unfounded, but... I think we should either do a fixinclude that would "work" for C and ASM (like #include vxCpu for ASM, vxTypesOld otherwise), or simply remove this hack (just using the fixinclude parlance here). My inclination would be for the latter. First, I'm not convinced fixincludes should be in the business of dealing with that kind of issue, the proper resolution of which depends on context. Then if this triggers a failure for some user, it would only show up for people upgrading the toolchain, which always calls for particular attention and often goes with adjustments. The symptom would be a compilation failure, easy to address if you can modify sources, with changes that you'd need to do if you were compiling with the system toolchain anyway, and which can be done with a manual fixinclude like trick if really needed. Finally, - this would only be visible in cases where the headers needed by regs.h aren't already #included, - there are probably not many users of the upstream gcc for VxWorks, and - I know that at least some of them (us) don't use fixincludes to begin with. So the risk of breaking existing C code seems very low for starters. What happens on your end if you just remove the hack ?
