[Qemu-devel] Re: [PATCH 2/3] Replace remaining gcc format attribute by macro GCC_FMT_ATTR (format checking)

[Blue Swirl]

On Thu, Sep 23, 2010 at 8:44 PM, Stefan Weil <address@hidden> wrote:
> Am 23.09.2010 22:33, schrieb Blue Swirl:
>>
>> On Thu, Sep 23, 2010 at 7:28 PM, Stefan Weil <address@hidden> wrote:
>>>
>>> Replace the remaining format attribute printf by macro
>>> GCC_FMT_ATTR which uses gnu_printf (if supported).
>>>
>>> This needs additional code changes:
>>>
>>> * Add qemu-common.h (which defined GCC_FMT_ATTR) were needed.
>>>
>>> * Remove standard includes when qemu-common.h was added.
>>>  qemu-common.h already provides these includes.
>>>
>>> * Remove local definitions which now come from stdio.h.
>>>  These definitions were needed before tcg was introduced.
>>>  They raise conflicts when qemu-common.h is included.
>>
>> IIRC the problem was that some system headers were incompatible with
>> global asm variables. There is still one, AREG0.
>>
>> But I'd rather not keep the hideous local definitions forever. Maybe
>> those systems which are broken by the patch are not interesting
>> anymore?
>
> Are there such systems? Or did the problems with earlier
> versions arise from the fact that a lot of global asm variables
> were reserved by qemu? How could a correctly defined AREG0
> interfere with system headers?

One explanation is that the code in target-*/op_helper.c may assume
that env/AREG0 is always available but since library functions may
clobber that, we want to hide them.

> For linux and win32, I did not notice problems caused by these changes.

It looks like that code has origins in one of the very first patches,
r16 or ba1c6e37fc5efc0f3d1e50d0760f9f4a1061187b. It was moved from
exec-i386.h to dyngen-exec.h by r236 or
79638566e5b87058e92f537b989df0dbc23f8b41. R997 or
1e6cae953d6a37216359b79e05d23e1bf4dc6bbe added a warning about system
headers. The commits around that add OS X support, maybe the problem
was there?