On 2018-09-03 14:11, Olivier Hainque wrote:
> Hi Rasmus,
>
>> On 27 Jun 2018, at 16:27, Rasmus Villemoes <r...@rasmusvillemoes.dk> wrote:
>> * inclhack.def (AAB_vxworks_regs_vxtypes): Guard include of
>> types/vxTypesOld.h by #ifndef _ASMLANGUAGE.
>> * fixincl.x: Regenerate.
>> ---
>> fixincludes/inclhack.def | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
>> index c1f5a13eda4..bac0079b69f 100644
>> --- a/fixincludes/inclhack.def
>> +++ b/fixincludes/inclhack.def
>> @@ -426,7 +426,9 @@ fix = {
>> replace = <<- _EndOfHeader_
>> #ifndef _REGS_H
>> #define _REGS_H
>> + #ifndef _ASMLANGUAGE
>> #include <types/vxTypesOld.h>
>> + #endif
>> #include_next <arch/../regs.h>
>> #endif
>> _EndOfHeader_;
>
> This will really look puzzling to a reader and would
> at least deserve a comment.
Hm, yes, that might be a good idea.
> How do we not get in assembly the problems we'd get in C
> when not including vxTypesOld ?
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...
[1] There's not much explanation in 74ee6ab5823c . Also, while since
fixed, that commit added wrong definitions of UINT8_MAX et al (type
promotion issue). So maybe that commit was just a bit hastily added.
Rasmus
