[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] fuzz, test x86_emulator: disable sse before including always_inline fns



>>> On 25.09.18 at 01:17, <christopher.w.clark@xxxxxxxxx> wrote:
> On Mon, Sep 24, 2018 at 5:06 AM Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>
>> >>> On 21.09.18 at 21:25, <christopher.w.clark@xxxxxxxxx> wrote:
>> >
>> > Adds necessary (previously missing) #include <stdio.h> to x86-emulate.h
>>
>> Why "necessary (previously missing)"? I can't seem to be able to
>> spot anything in that header that would depend on stdio.h.
> 
> When WRAP is defined prior to including x86-emulate.h, it introduces
> the need for stdio.h to be included to avoid:
> 
> | x86-emulate.h:83:6: error: 'fwrite' undeclared here (not in a
> function); did you mean 'free'?
> |  WRAP(fwrite);
> 
> and similar for the other wrapped functions.
> 
> It was fine previously as wrapper.c included <stdio.h> prior to 
> "x86-emulate.h"
> but that gets changed with this commit. I'll rewrite that part of the commit
> message though, and I'll also made the new <stdio.h> inclusion
> dependent on WRAP,
> since WRAP being defined is what prompts the need for it.

But that's (in my opinion) a requirement towards the file defining
WRAP then, not towards the header.

>> >  #if __GNUC__ >= 6
>> >  #pragma GCC target("no-sse")
>> >  #endif
>>
>> I think the right approach would be to move this to the top of the
>> file, ahead of all #include-s. However, I vaguely recall this not
>> having worked on at least some systems back when I had
>> introduced it.
> 
> Yes, this is still the case, failing in my development environment at least.
> Declaration of atof fails with: "SSE register return with SSE disabled".

Hmm - I (now) wonder whether -mfpmath= could help here.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.