[Qemu-devel] Build failure on OS X

[Qemu-devel] Build failure on OS X

[Andreas Färber]

Hello,

Anyone any idea what might've caused this build failure? I'm fairly  
certain I haven't messed with or updated the system headers.

gcc-3.3 -Wall -O2 -g -fno-strict-aliasing -I. -I.. -I/Users/andreas/Q/ 
myqemu/target-sparc -I/Users/andreas/Q/myqemu -D__powerpc__ - 
D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/Users/ 
andreas/Q/myqemu/fpu -I/Users/andreas/Q/myqemu/slirp  -mdynamic-no- 
pic  -c -o block-raw.o /Users/andreas/Q/myqemu/block-raw.c
In file included from /usr/include/math.h:26,
                  from /System/Library/Frameworks/ 
CoreFoundation.framework/Headers/CoreFoundation.h:19,
                  from /Users/andreas/Q/myqemu/block-raw.c:43:
/usr/include/architecture/ppc/math.h:284: error: parse error before  
"__attribute__"
/usr/include/architecture/ppc/math.h:284: error: parse error before  
')' token
/usr/include/architecture/ppc/math.h:285: error: parse error before  
"__attribute__"
/usr/include/architecture/ppc/math.h:285: error: parse error before  
')' token
/usr/include/architecture/ppc/math.h:286: error: parse error before  
"__attribute__"
/usr/include/architecture/ppc/math.h:286: error: parse error before  
')' token
/usr/include/architecture/ppc/math.h:287: error: parse error before  
"__attribute__"
/usr/include/architecture/ppc/math.h:287: error: parse error before  
')' token
/usr/include/architecture/ppc/math.h:288: error: parse error before  
"__attribute__"
/usr/include/architecture/ppc/math.h:288: error: parse error before  
')' token
/usr/include/architecture/ppc/math.h:289: error: parse error before  
"__attribute__"
/usr/include/architecture/ppc/math.h:289: error: parse error before  
')' token
/usr/include/architecture/ppc/math.h:290: error: parse error before  
"__attribute__"
/usr/include/architecture/ppc/math.h:290: error: parse error before  
')' token
/usr/include/architecture/ppc/math.h:291: error: parse error before  
"__attribute__"
/usr/include/architecture/ppc/math.h:291: error: parse error before  
')' token
/usr/include/architecture/ppc/math.h:292: error: parse error before  
"__attribute__"
/usr/include/architecture/ppc/math.h:292: error: parse error before  
')' token
/usr/include/architecture/ppc/math.h:293: error: parse error before  
"__attribute__"
/usr/include/architecture/ppc/math.h:293: error: parse error before  
')' token
/usr/include/architecture/ppc/math.h:294: error: parse error before  
"__attribute__"
/usr/include/architecture/ppc/math.h:294: error: parse error before  
')' token
/usr/include/architecture/ppc/math.h:295: error: parse error before  
"__attribute__"
/usr/include/architecture/ppc/math.h:295: error: parse error before  
')' token
/usr/include/architecture/ppc/math.h:296: error: parse error before  
"__attribute__"
/usr/include/architecture/ppc/math.h:296: error: parse error before  
')' token
/usr/include/architecture/ppc/math.h:297: error: parse error before  
"__attribute__"
/usr/include/architecture/ppc/math.h:297: error: parse error before  
')' token
/usr/include/architecture/ppc/math.h:298: error: parse error before  
"__attribute__"
/usr/include/architecture/ppc/math.h:298: error: parse error before  
')' token
make[1]: *** [block-raw.o] Error 1

With line 284 of math.h reading:
		static __inline__ int __inline_isfinitef	(float      )  
__MATH_H_ALWAYS_INLINE__;

Thanks,
Andreas

Re: [Qemu-devel] Build failure on OS X

[J. Mayer]

On Sun, 2007-09-30 at 12:09 +0200, Andreas Färber wrote:
> Hello,

Hi,

> Anyone any idea what might've caused this build failure? I'm fairly  
> certain I haven't messed with or updated the system headers.

have you just updated your CVS co ?
Please try to comment the "always_inline" definition in vl.h /
exec-all.h.
If this is what's breaking your build, I'll revert this definition.

[...]

> With line 284 of math.h reading:
> 		static __inline__ int __inline_isfinitef	(float      )  
> __MATH_H_ALWAYS_INLINE__;

The fact the error mentions "__attribute__" and ALWAYS_INLINE make me
think the always_inline defintion is the suspect here....

Regards.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] Build failure on OS X

[Andreas Färber]

Hi,

Am 30.09.2007 um 13:45 schrieb J. Mayer:

>> Anyone any idea what might've caused this build failure? I'm fairly
>> certain I haven't messed with or updated the system headers.
>
> have you just updated your CVS co ?

Yes.

> Please try to comment the "always_inline" definition in vl.h /
> exec-all.h.
> If this is what's breaking your build, I'll revert this definition.

It is, thanks for the pointer! (The source file itself didn't appear  
to have been updated.)

>> With line 284 of math.h reading:
>> 		static __inline__ int __inline_isfinitef	(float      )
>> __MATH_H_ALWAYS_INLINE__;
>
> The fact the error mentions "__attribute__" and ALWAYS_INLINE make me
> think the always_inline defintion is the suspect here....

I believe Apple's GCC in general has a problem with the __attribute__  
notation. The ppc*-softmmu fail to build for some time due to its use  
for aliasing in hw/ppc.c. Maybe we could add a configure check for  
this feature to have a conditional define? That would allow a more  
elegant fix than the one I use locally and had previously suggested.

Best regards,

Andreas

Re: [Qemu-devel] Build failure on OS X

[J. Mayer]

On Sun, 2007-09-30 at 14:05 +0200, Andreas Färber wrote:
> Hi,
> 
> Am 30.09.2007 um 13:45 schrieb J. Mayer:
> 
> >> Anyone any idea what might've caused this build failure? I'm fairly
> >> certain I haven't messed with or updated the system headers.
> >
> > have you just updated your CVS co ?
> 
> Yes.
> 
> > Please try to comment the "always_inline" definition in vl.h /
> > exec-all.h.
> > If this is what's breaking your build, I'll revert this definition.
> 
> It is, thanks for the pointer! (The source file itself didn't appear  
> to have been updated.)
> 
> >> With line 284 of math.h reading:
> >> 		static __inline__ int __inline_isfinitef	(float      )
> >> __MATH_H_ALWAYS_INLINE__;
> >
> > The fact the error mentions "__attribute__" and ALWAYS_INLINE make me
> > think the always_inline defintion is the suspect here....
> 
> I believe Apple's GCC in general has a problem with the __attribute__  
> notation. The ppc*-softmmu fail to build for some time due to its use  
> for aliasing in hw/ppc.c. Maybe we could add a configure check for  
> this feature to have a conditional define? That would allow a more  
> elegant fix than the one I use locally and had previously suggested.

Sorry for introducing this problem...
Would this new definition solve the compilation failure ?

#ifndef always_inline
#if (__GNUC__ < 3) || defined(__APPLE__)
#define always_inline inline
#else
#define always_inline __attribute__ (( always_inline )) inline
#endif
#endif

Regards.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] Build failure on OS X

[Andreas Färber]

[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]


Am 30.09.2007 um 14:17 schrieb J. Mayer:

> On Sun, 2007-09-30 at 14:05 +0200, Andreas Färber wrote:
>> Hi,
>>
>> Am 30.09.2007 um 13:45 schrieb J. Mayer:
>>
>>>> Anyone any idea what might've caused this build failure? I'm fairly
>>>> certain I haven't messed with or updated the system headers.
>>>
>>> have you just updated your CVS co ?
>>
>> Yes.
>>
>>> Please try to comment the "always_inline" definition in vl.h /
>>> exec-all.h.
>>> If this is what's breaking your build, I'll revert this definition.
>>
>> It is, thanks for the pointer! (The source file itself didn't appear
>> to have been updated.)
>>
>>>> With line 284 of math.h reading:
>>>> 		static __inline__ int __inline_isfinitef	(float      )
>>>> __MATH_H_ALWAYS_INLINE__;
>>>
>>> The fact the error mentions "__attribute__" and ALWAYS_INLINE  
>>> make me
>>> think the always_inline defintion is the suspect here....
>>
>> I believe Apple's GCC in general has a problem with the __attribute__
>> notation. The ppc*-softmmu fail to build for some time due to its use
>> for aliasing in hw/ppc.c. Maybe we could add a configure check for
>> this feature to have a conditional define? That would allow a more
>> elegant fix than the one I use locally and had previously suggested.
>
> Sorry for introducing this problem...
> Would this new definition solve the compilation failure ?
>
> #ifndef always_inline
> #if (__GNUC__ < 3) || defined(__APPLE__)
> #define always_inline inline
> #else
> #define always_inline __attribute__ (( always_inline )) inline
> #endif
> #endif

It does.

I've updated my patch accordingly with __APPLE__, what do you think?  
I have no idea what alias does exactly, should we just use a #define  
on the Mac?

Regards,

Andreas

[-- Attachment #2: ppc.c-2007-09-30.diff --]
[-- Type: application/octet-stream, Size: 362 bytes --]

Index: hw/ppc.c
===================================================================
RCS file: /sources/qemu/qemu/hw/ppc.c,v
retrieving revision 1.27
diff -r1.27 ppc.c
740a741,745
> #ifdef __APPLE__
> {
> 	cpu_ppc_store_tbu(env, value);
> }
> #else
741a747
> #endif
743a750,754
> #ifdef __APPLE__
> {
> 	return cpu_ppc_load_tbu(env);
> }
> #else
744a756
> #endif

Re: [Qemu-devel] Build failure on OS X

[J. Mayer]

[-- Attachment #1: Type: text/plain, Size: 2426 bytes --]

On Sun, 2007-09-30 at 15:08 +0200, Andreas Färber wrote:
> Am 30.09.2007 um 14:17 schrieb J. Mayer:
> 
> > On Sun, 2007-09-30 at 14:05 +0200, Andreas Färber wrote:
> >> Hi,
> >>
> >> Am 30.09.2007 um 13:45 schrieb J. Mayer:
> >>
> >>>> Anyone any idea what might've caused this build failure? I'm fairly
> >>>> certain I haven't messed with or updated the system headers.
> >>>
> >>> have you just updated your CVS co ?
> >>
> >> Yes.
> >>
> >>> Please try to comment the "always_inline" definition in vl.h /
> >>> exec-all.h.
> >>> If this is what's breaking your build, I'll revert this definition.
> >>
> >> It is, thanks for the pointer! (The source file itself didn't appear
> >> to have been updated.)
> >>
> >>>> With line 284 of math.h reading:
> >>>> 		static __inline__ int __inline_isfinitef	(float      )
> >>>> __MATH_H_ALWAYS_INLINE__;
> >>>
> >>> The fact the error mentions "__attribute__" and ALWAYS_INLINE  
> >>> make me
> >>> think the always_inline defintion is the suspect here....
> >>
> >> I believe Apple's GCC in general has a problem with the __attribute__
> >> notation. The ppc*-softmmu fail to build for some time due to its use
> >> for aliasing in hw/ppc.c. Maybe we could add a configure check for
> >> this feature to have a conditional define? That would allow a more
> >> elegant fix than the one I use locally and had previously suggested.
> >
> > Sorry for introducing this problem...
> > Would this new definition solve the compilation failure ?
> >
> > #ifndef always_inline
> > #if (__GNUC__ < 3) || defined(__APPLE__)
> > #define always_inline inline
> > #else
> > #define always_inline __attribute__ (( always_inline )) inline
> > #endif
> > #endif
> 
> It does.

OK, then I will commit this fixup, even if it may generate slower code
for interrupt processing (which is already something slow...).

> I've updated my patch accordingly with __APPLE__, what do you think?  
> I have no idea what alias does exactly, should we just use a #define  
> on the Mac?

the alias attribute is used to define a new function name that actually
refer to another existant function, this to avoid code duplication. We
can easily avoid using it using an inline function for the actual
implementation and calling it from different places. Please take a look
at this patch.

Regards.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

[-- Attachment #2: ppc_alias.diff --]
[-- Type: text/x-patch, Size: 1883 bytes --]

Index: hw/ppc.c
===================================================================
RCS file: /sources/qemu/qemu/hw/ppc.c,v
retrieving revision 1.27
diff -u -d -d -p -r1.27 ppc.c
--- hw/ppc.c	30 Sep 2007 00:38:37 -0000	1.27
+++ hw/ppc.c	30 Sep 2007 13:26:43 -0000
@@ -445,7 +445,7 @@ uint32_t cpu_ppc_load_tbl (CPUState *env
     return tb & 0xFFFFFFFF;
 }
 
-uint32_t cpu_ppc_load_tbu (CPUState *env)
+static inline uint32_t _cpu_ppc_load_tbu (CPUState *env)
 {
     ppc_tb_t *tb_env = env->tb_env;
     uint64_t tb;
@@ -460,6 +460,11 @@ uint32_t cpu_ppc_load_tbu (CPUState *env
     return tb >> 32;
 }
 
+uint32_t cpu_ppc_load_tbu (CPUState *env)
+{
+    return _cpu_ppc_load_tbu(env);
+}
+
 static inline void cpu_ppc_store_tb (ppc_tb_t *tb_env, int64_t *tb_offsetp,
                                      uint64_t value)
 {
@@ -483,7 +488,7 @@ void cpu_ppc_store_tbl (CPUState *env, u
     cpu_ppc_store_tb(tb_env, &tb_env->tb_offset, tb | (uint64_t)value);
 }
 
-void cpu_ppc_store_tbu (CPUState *env, uint32_t value)
+static inline void _cpu_ppc_store_tbu (CPUState *env, uint32_t value)
 {
     ppc_tb_t *tb_env = env->tb_env;
     uint64_t tb;
@@ -494,6 +499,11 @@ void cpu_ppc_store_tbu (CPUState *env, u
                      ((uint64_t)value << 32) | tb);
 }
 
+void cpu_ppc_store_tbu (CPUState *env, uint32_t value)
+{
+    _cpu_ppc_store_tbu(env, value);
+}
+
 uint32_t cpu_ppc_load_atbl (CPUState *env)
 {
     ppc_tb_t *tb_env = env->tb_env;
@@ -738,10 +748,14 @@ clk_setup_cb cpu_ppc601_rtc_init (CPUSta
 }
 
 void cpu_ppc601_store_rtcu (CPUState *env, uint32_t value)
-__attribute__ (( alias ("cpu_ppc_store_tbu") ));
+{
+    _cpu_ppc_store_tbu(env, value);
+}
 
 uint32_t cpu_ppc601_load_rtcu (CPUState *env)
-__attribute__ (( alias ("cpu_ppc_load_tbu") ));
+{
+    return _cpu_ppc_load_tbu(env);
+}
 
 void cpu_ppc601_store_rtcl (CPUState *env, uint32_t value)
 {

Re: [Qemu-devel] Build failure on OS X

[Andreas Färber]

Am 30.09.2007 um 15:27 schrieb J. Mayer:

> On Sun, 2007-09-30 at 15:08 +0200, Andreas Färber wrote:
>> Am 30.09.2007 um 14:17 schrieb J. Mayer:
>>> Would this new definition solve the compilation failure ?
>>>
>>> #ifndef always_inline
>>> #if (__GNUC__ < 3) || defined(__APPLE__)
>>> #define always_inline inline
>>> #else
>>> #define always_inline __attribute__ (( always_inline )) inline
>>> #endif
>>> #endif
>>
>> It does.
>
> OK, then I will commit this fixup, even if it may generate slower code
> for interrupt processing (which is already something slow...).

Well, slower compared to Linux certainly, but there's no fancy  
acceleration anyway. I consider working+slow better than not working  
at all.
If someone has a speedup idea for the __APPLE__ case, that could  
still be applied separately.


> the alias attribute is used to define a new function name that  
> actually
> refer to another existant function, this to avoid code duplication. We
> can easily avoid using it using an inline function for the actual
> implementation and calling it from different places. Please take a  
> look
> at this patch.

Patch looks okay to me and compiles. Again, I have no idea about the  
implications and any performance impact.


Either way, if I run "qemu-system-ppc -boot d -cdrom debian-40r0- 
powerpc-DVD-1.iso" this is what I get:

starting qemu...
qemu: fatal: Unable to find PowerPC CPU definition

NIP fffffffc LR 00000000 CTR 00000000
Bus error

I haven't used it in a while; as reported earlier, it didn't really  
work back then either, but it worked "more", i.e. started to boot.  
But this is with or without the patch, so unrelated - just saying I  
can't confirm that this patch works 100%.

Regards,

Andreas


P.S. I'm subscribed, you don't need to CC me. :)

Re: [Qemu-devel] Build failure on OS X

[J. Mayer]

On Sun, 2007-09-30 at 16:28 +0200, Andreas Färber wrote:
> Am 30.09.2007 um 15:27 schrieb J. Mayer:
> 
> > On Sun, 2007-09-30 at 15:08 +0200, Andreas Färber wrote:
> >> Am 30.09.2007 um 14:17 schrieb J. Mayer:
> >>> Would this new definition solve the compilation failure ?
> >>>
> >>> #ifndef always_inline
> >>> #if (__GNUC__ < 3) || defined(__APPLE__)
> >>> #define always_inline inline
> >>> #else
> >>> #define always_inline __attribute__ (( always_inline )) inline
> >>> #endif
> >>> #endif
> >>
> >> It does.
> >
> > OK, then I will commit this fixup, even if it may generate slower code
> > for interrupt processing (which is already something slow...).
> 
> Well, slower compared to Linux certainly, but there's no fancy  
> acceleration anyway. I consider working+slow better than not working  
> at all.

I fully agree...

> If someone has a speedup idea for the __APPLE__ case, that could  
> still be applied separately.

I guess there are some already defined macros in the Apple build
environmnet that should be used instead. But I don't know too much about
this environment... The slowdown is really not an issue in that
particular case.

> > the alias attribute is used to define a new function name that  
> > actually
> > refer to another existant function, this to avoid code duplication. We
> > can easily avoid using it using an inline function for the actual
> > implementation and calling it from different places. Please take a  
> > look
> > at this patch.
> 
> Patch looks okay to me and compiles. Again, I have no idea about the  
> implications and any performance impact.

It has no performance impact, it just duplicates one (small) function in
the generated object, which will not have any impact.

> Either way, if I run "qemu-system-ppc -boot d -cdrom debian-40r0- 
> powerpc-DVD-1.iso" this is what I get:
> 
> starting qemu...
> qemu: fatal: Unable to find PowerPC CPU definition
> 
> NIP fffffffc LR 00000000 CTR 00000000
> Bus error

> I haven't used it in a while; as reported earlier, it didn't really  
> work back then either, but it worked "more", i.e. started to boot.  
> But this is with or without the patch, so unrelated - just saying I  
> can't confirm that this patch works 100%.

OK, just checked and I have this problem too. Will fix it as soon as I
can.
In between, you can just try to force the CPU, adding '-cpu 750' or
'-cpu 604' to your command line.

Thanks for this report !

Regards.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] Build failure on OS X

[Andreas Färber]

Am 30.09.2007 um 16:37 schrieb J. Mayer:

>> If someone has a speedup idea for the __APPLE__ case, that could
>> still be applied separately.
>
> I guess there are some already defined macros in the Apple build
> environmnet that should be used instead. But I don't know too much  
> about
> this environment... The slowdown is really not an issue in that
> particular case.

Actually, I am now seeing that in math.h Apple itself uses  
__attribute__ ((always_inline)) for __MATH_H_ALWAYS_INLINE__ if  
__GNUC__ is defined ... so I now believe the issue is rather the  
"recursive" definition of always_inline: QEMU defines always_inline  
and it subsequently tries to replace always_inline inside the  
__attribute__(()) in math.h! Could this be it?


>> Either way, if I run "qemu-system-ppc -boot d -cdrom debian-40r0-
>> powerpc-DVD-1.iso" this is what I get:
>>
>> starting qemu...
>> qemu: fatal: Unable to find PowerPC CPU definition
>>
>> NIP fffffffc LR 00000000 CTR 00000000
>> Bus error
>
>> I haven't used it in a while; as reported earlier, it didn't really
>> work back then either, but it worked "more", i.e. started to boot.
>> But this is with or without the patch, so unrelated - just saying I
>> can't confirm that this patch works 100%.
>
> OK, just checked and I have this problem too. Will fix it as soon as I
> can.
> In between, you can just try to force the CPU, adding '-cpu 750' or
> '-cpu 604' to your command line.
>
> Thanks for this report !

Looks better, but still does not boot:

PMG5:~/Q/myqemu andreas$ ../latest/bin/qemu-system-ppc -boot d - 
cdrom ../debian-40r0-powerpc-DVD-1.iso -cpu 604 -nographic
starting qemu...
register PCI host 'pci' 'pci' 'grackle' 'MOT,MPC106'
register 'pci' 'pci' 'grackle' 'MOT,MPC106' 0x80000000 in 'device- 
tree' 0xffffffff
Done 582b000 582b880
PCI device '<null>' 0 0 0 has no reg properties:
PCI device '<null>' 0 0 0 has no assigned addresses properties:
register pci device 'Qemu VGA' 00000001 'display' 'VGA' 'Qemu VGA'
register 'Qemu VGA' 'display' 'VGA' 'Qemu VGA' 0x00000001 in 'pci'  
0x80000000
Done 582b880 582ba00
PCI device 'Qemu VGA' 0 1 0 reg properties:
   addr: 82000810 00000000 80000000 size: 00000000 00800000
PCI device 'Qemu VGA' 0 1 0 assigned addresses properties:
   addr: 82000810 00000000 80000000 size: 00000000 00800000
register pci device 'NE2000' 00000002 'network' '<null>' 'NE2000 PCI'
register 'NE2000' 'network' '<null>' 'NE2000 PCI' 0x00000002 in 'pci'  
0x80000000
Done 582b880 582bb00
PCI device 'NE2000' 0 2 0 reg properties:
   addr: 01001010 00000000 00001000 size: 00000000 00000100
PCI device 'NE2000' 0 2 0 assigned addresses properties:
   addr: 01001010 00000000 00001000 size: 00000000 00000100
register pci device 'pci-ata' 00000003 'pci-ide' '<null>' '<null>'
register 'pci-ata' 'pci-ide' '<null>' '<null>' 0x00000003 in 'pci'  
0x80000000
Done 582b880 582bc00
PCI device 'pci-ata' 0 3 0 reg properties:
   addr: 01001810 00000000 00001100 size: 00000000 00000100
   addr: 01001814 00000000 00001200 size: 00000000 00000100
   addr: 01001818 00000000 00001300 size: 00000000 00000100
   addr: 0100181c 00000000 00001400 size: 00000000 00000100
   addr: 01001820 00000000 00001500 size: 00000000 00000100
PCI device 'pci-ata' 0 3 0 assigned addresses properties:
   addr: 01001810 00000000 00001100 size: 00000000 00000100
   addr: 01001814 00000000 00001200 size: 00000000 00000100
   addr: 01001818 00000000 00001300 size: 00000000 00000100
   addr: 0100181c 00000000 00001400 size: 00000000 00000100
   addr: 01001820 00000000 00001500 size: 00000000 00000100
register pci device 'mac-io' 00000004 'mac-io' 'paddingtonheathrow'  
'AAPL,343S1211'
register 'mac-io' 'mac-io' 'paddingtonheathrow' 'AAPL,343S1211'  
0x00000004 in 'pci' 0x80000000
Done 582b880 582be80
PCI device 'mac-io' 0 4 0 reg properties:
   addr: 82002010 00000000 80880000 size: 00000000 00080000
PCI device 'mac-io' 0 4 0 assigned addresses properties:
   addr: 82002010 00000000 80880000 size: 00000000 00080000
PPC Open Hack'Ware BIOS for qemu version 0.4.1
Build 2005-07-06 23:10:57
Copyright 2003-2005 Jocelyn Mayer

Memory size: 144 MB.
Booting from device d
ide0: drive 0: none
ide0: drive 1: CD-ROM
ERROR: OF_property_copy cannot get property 'cd' for aliases
ERROR: ATAPI TEST_UNIT_READY : status 48 != 0x08
ide1: drive 0: none
ide1: drive 1: none
ERROR: Found no boot partition!


Same for the other -cpu.

Regards,

Andreas

Re: [Qemu-devel] Build failure on OS X

[Andreas Färber]

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]


Am 30.09.2007 um 17:05 schrieb Andreas Färber:

> Am 30.09.2007 um 16:37 schrieb J. Mayer:
>
>>> If someone has a speedup idea for the __APPLE__ case, that could
>>> still be applied separately.
>>
>> I guess there are some already defined macros in the Apple build
>> environmnet that should be used instead. But I don't know too much  
>> about
>> this environment... The slowdown is really not an issue in that
>> particular case.
>
> Actually, I am now seeing that in math.h Apple itself uses  
> __attribute__ ((always_inline)) for __MATH_H_ALWAYS_INLINE__ if  
> __GNUC__ is defined ... so I now believe the issue is rather the  
> "recursive" definition of always_inline: QEMU defines always_inline  
> and it subsequently tries to replace always_inline inside the  
> __attribute__(()) in math.h! Could this be it?

Puzzling, the attached patch works. It appears to be the trailing  
inline that it doesn't like for some reason.

Regards,

Andreas

[-- Attachment #2: vl.h-exec-all.h-inline-2007-09-30.diff --]
[-- Type: application/octet-stream, Size: 677 bytes --]

Index: vl.h
===================================================================
RCS file: /sources/qemu/qemu/vl.h,v
retrieving revision 1.273
diff -r1.273 vl.h
113c113
< #if (__GNUC__ < 3) || defined(__APPLE__)
---
> #if (__GNUC__ < 3)
114a115,116
> #elif defined(__APPLE__)
> #define always_inline __attribute__ (( always_inline ))
Index: exec-all.h
===================================================================
RCS file: /sources/qemu/qemu/exec-all.h,v
retrieving revision 1.66
diff -r1.66 exec-all.h
41c41
< #if (__GNUC__ < 3) || defined(__APPLE__)
---
> #if (__GNUC__ < 3)
42a43,44
> #elif defined(__APPLE__)
> #define always_inline __attribute__ (( always_inline ))

[-- Attachment #3: Type: text/plain, Size: 1 bytes --]

Re: [Qemu-devel] Build failure on OS X

[J. Mayer]

On Sun, 2007-09-30 at 17:05 +0200, Andreas Färber wrote:
> Am 30.09.2007 um 16:37 schrieb J. Mayer:
> 
> >> If someone has a speedup idea for the __APPLE__ case, that could
> >> still be applied separately.
> >
> > I guess there are some already defined macros in the Apple build
> > environmnet that should be used instead. But I don't know too much  
> > about
> > this environment... The slowdown is really not an issue in that
> > particular case.
> 
> Actually, I am now seeing that in math.h Apple itself uses  
> __attribute__ ((always_inline)) for __MATH_H_ALWAYS_INLINE__ if  
> __GNUC__ is defined ... so I now believe the issue is rather the  
> "recursive" definition of always_inline: QEMU defines always_inline  
> and it subsequently tries to replace always_inline inside the  
> __attribute__(()) in math.h! Could this be it?
> 
> 
> >> Either way, if I run "qemu-system-ppc -boot d -cdrom debian-40r0-
> >> powerpc-DVD-1.iso" this is what I get:
> >>
> >> starting qemu...
> >> qemu: fatal: Unable to find PowerPC CPU definition
> >>
> >> NIP fffffffc LR 00000000 CTR 00000000
> >> Bus error
> >
> >> I haven't used it in a while; as reported earlier, it didn't really
> >> work back then either, but it worked "more", i.e. started to boot.
> >> But this is with or without the patch, so unrelated - just saying I
> >> can't confirm that this patch works 100%.
> >
> > OK, just checked and I have this problem too. Will fix it as soon as I
> > can.
> > In between, you can just try to force the CPU, adding '-cpu 750' or
> > '-cpu 604' to your command line.
> >
> > Thanks for this report !
> 
> Looks better, but still does not boot:

There are known issues with the PowerPC emulation:
Prep has been broken long ago by PCI patches. One has reported the exact
patch that did break it but the ones who did that patch never felt like
he has to take care of making it work properly and I did not have time
or motivation to search more.
As far as I know, the mac99 target is the one known to run but
unfortunately some patches have broken the IDE CDROM support during this
summer. I will have to find a work-around in the firmware as I also
noticed that it was bugged when ran on real hardware. For now, I do all
my test booting on hard drive disk images or flash images (for PowerPC
405). I'm currently working on the core emulation but I will come back
to do some fixes in the hw part / firmware part soon.

[....]

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] Build failure on OS X

[Andreas Färber]

Am 30.09.2007 um 17:54 schrieb Andreas Färber:

>
> Am 30.09.2007 um 17:05 schrieb Andreas Färber:
>
>> Am 30.09.2007 um 16:37 schrieb J. Mayer:
>>
>>>> If someone has a speedup idea for the __APPLE__ case, that could
>>>> still be applied separately.
>>>
>>> I guess there are some already defined macros in the Apple build
>>> environmnet that should be used instead. But I don't know too  
>>> much about
>>> this environment... The slowdown is really not an issue in that
>>> particular case.
>>
>> Actually, I am now seeing that in math.h Apple itself uses  
>> __attribute__ ((always_inline)) for __MATH_H_ALWAYS_INLINE__ if  
>> __GNUC__ is defined ... so I now believe the issue is rather the  
>> "recursive" definition of always_inline: QEMU defines  
>> always_inline and it subsequently tries to replace always_inline  
>> inside the __attribute__(()) in math.h! Could this be it?
>
> Puzzling, the attached patch works. It appears to be the trailing  
> inline that it doesn't like for some reason.

Just scratch it... On second tests it doesn't work at all, I could've  
sworn I did make distclean before building...