On Thu, Sep 23, 2010 at 8:44 PM, Stefan Weil <w...@mail.berlios.de> wrote: > Am 23.09.2010 22:33, schrieb Blue Swirl: >> >> On Thu, Sep 23, 2010 at 7:28 PM, Stefan Weil <w...@mail.berlios.de> 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?
