On 2018-09-14 14:39, Olivier Hainque wrote:
>
>
>> On 13 Sep 2018, at 00:25, Rasmus Villemoes 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
> On 13 Sep 2018, at 00:25, Rasmus Villemoes 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.20180
On 2018-09-05 11:38, Olivier Hainque wrote:
> Hi Rasmus,
>
> 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
Hi Rasmus,
> On 3 Sep 2018, at 15:20, Rasmus Villemoes 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.
> Wel
> On 3 Sep 2018, at 17:25, Bruce Korb wrote:
>
> On Mon, Sep 3, 2018 at 2:46 AM Olivier Hainque wrote:
>>> -"#define ioctl(fd, func, arg) (ioctl)(fd, func, (int)(arg))\n";
>>> +"#define ioctl(fd, func, arg) ioctl(fd, func, (int)(arg))\n";
>>
>> ok by me, thanks.
>
> Shouldn'
On Mon, Sep 3, 2018 at 2:46 AM Olivier Hainque wrote:
> > -"#define ioctl(fd, func, arg) (ioctl)(fd, func, (int)(arg))\n";
> > +"#define ioctl(fd, func, arg) ioctl(fd, func, (int)(arg))\n";
>
> ok by me, thanks.
Shouldn't this qualify as "trivial"? :)
On 2018-09-03 14:11, Olivier Hainque wrote:
> Hi Rasmus,
>
>> On 27 Jun 2018, at 16:27, Rasmus Villemoes wrote:
>> * inclhack.def (AAB_vxworks_regs_vxtypes): Guard include of
>> types/vxTypesOld.h by #ifndef _ASMLANGUAGE.
>> * fixincl.x: Regenerate.
>> ---
>> fixincludes/inclhack.d
Hi Rasmus,
> On 27 Jun 2018, at 16:27, Rasmus Villemoes 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(+)
>
> di
Hi Rasmus,
> On 29 Jun 2018, at 11:47, Rasmus Villemoes wrote:
> -"#define ioctl(fd, func, arg) (ioctl)(fd, func, (int)(arg))\n";
> +"#define ioctl(fd, func, arg) ioctl(fd, func, (int)(arg))\n";
ok by me, thanks.
The rationale for the fixinclude ioctl macro wrapper is, as far as I can
tell (https://gcc.gnu.org/ml/gcc-patches/2012-09/msg01619.html)
Fix 2: Add hack for ioctl() on VxWorks.
ioctl() is supposed to be variadic, but VxWorks only has a three
argument version with the third argument of type
VxWorks' regs.h does include some files that need types defined in
vxTypesOld.h, and it does not itself include that header, directly or
indirectly. Moreover, vxTypesOld.h ends up pulling in definitions of
various cpufamily macros (from types/vxCpu.h) that are also needed
directly by regs.h.
Howev
On 06/10/2012 02:38 PM, Bruce Korb wrote:
On Sun, Jun 10, 2012 at 10:57 AM, Nathan Sidwell wrote:
On 06/06/12 17:33, rbmj wrote:
Hi everyone,
This patch series is the result of this [1] thread about fixincludes on
VxWorks.
It resolves bugs 53457 and 53378, and a few other issues that previous
On Sun, Jun 10, 2012 at 10:57 AM, Nathan Sidwell wrote:
> On 06/06/12 17:33, rbmj wrote:
>>
>> Hi everyone,
>>
>> This patch series is the result of this [1] thread about fixincludes on
>> VxWorks.
>> It resolves bugs 53457 and 53378, and a few other issues that previously
>> required manual inter
On 06/06/12 17:33, rbmj wrote:
Hi everyone,
This patch series is the result of this [1] thread about fixincludes on VxWorks.
It resolves bugs 53457 and 53378, and a few other issues that previously
required manual intervention to fix for VxWorks header files.
From a vxworks POV these all look
On 06/06/2012 01:11 PM, Bruce Korb wrote:
On 06/06/12 09:33, rbmj wrote:
Hi everyone,
OK, I'm slow. I just woke up from a late night. "test -r vxWorks.h"
is the mechanism to ensure that tests only fire on a vxworks platform.
Seems a bit obscure, but if it is easier than other mechanisms, the
On 06/06/12 09:33, rbmj wrote:
Hi everyone,
OK, I'm slow. I just woke up from a late night. "test -r vxWorks.h"
is the mechanism to ensure that tests only fire on a vxworks platform.
Seems a bit obscure, but if it is easier than other mechanisms, then
fine. I do think a "mach" test would be
Please read README and look to inclhack.def for examples
approximating the kind of testing you are interested in doing.
"test -r vxWorks.h" is a pointless test if you configure the fix
to apply only to a file named vxWorks.h.
On Wed, Jun 6, 2012 at 9:33 AM, rbmj wrote:
> Hi everyone,
>
> This pat
Hi everyone,
This patch series is the result of this [1] thread about fixincludes on
VxWorks. It resolves bugs 53457 and 53378, and a few other issues that
previously required manual intervention to fix for VxWorks header files.
The fixes are tested and work correctly both with make stmp-fix
18 matches
Mail list logo
