Closed GoogleCodeExporter closed 9 years ago
The attached program runs for me on x86. Something strange is going on with
your compiler's floating point,
because it's producing this:
+001b8 00002860 00B0A0E3 mov fp,#0x0
+001bc 00002864 800047E2 sub r0,r7,#0x80
+001c0 00002868 00B08DE4 str fp,[sp]
+001c4 0000286c 0B10A0E1 mov r1,fp
+001c8 00002870 0B20A0E1 mov r2,fp
+001cc 00002874 0B30A0E1 mov r3,fp
+001d0 00002878 BD0000EB bl CGRectMake
i.e. it's calling CGRectMake(0, 0, 0, 0)!! Unfortunately I can't reproduce this
myself, because your source
compiles and runs perfectly for me.
Original comment by nightwat...@gmail.com
on 13 Sep 2007 at 2:20
I wonder if it's an assembler problem. Could you compile using the -save-temps
option to GCC and send me
the HelloApplication.s file?
Original comment by nightwat...@gmail.com
on 13 Sep 2007 at 2:25
Original comment by nightwat...@gmail.com
on 13 Sep 2007 at 2:25
Here's the HelloApplication.s file compiled with the -save-temps flag.
Original comment by d...@linuxprogrammer.org
on 13 Sep 2007 at 3:52
Attachments:
Well, it is indeed a GCC problem. Somewhere in the middle end of LLVM-GCC
everything is getting all jammed
up w/r/t floating point numbers, but only on OS X PPC. Without a PPC to test
myself on there's nothing I can do.
Original comment by nightwat...@gmail.com
on 13 Sep 2007 at 4:02
Well, I'll help all I can. I noticed that I wasn't all caught up to head when I
built this toolchain. I missed the checkin from this afternoon so I'm
rebuilding
everything from scratch now.
Original comment by d...@linuxprogrammer.org
on 13 Sep 2007 at 4:06
Make sure that your ARM FP type is set correctly. The driver tries to set this
via a compile flag. Run gcc with -v
while building something and you should see a line such as the following:
/usr/local/libexec/gcc/arm-apple-darwin/4.0.1/cc1obj -quiet -v -D__DYNAMIC__ synchronized.m -fPIC -
mfpu=vfp -mcpu=arm1176jzf-s -quiet -dumpbase synchronized.m
-mmacosx-version-min=10.4 -
auxbase synchronized -version -o /var/tmp//cc8oNlnF.s
Notice that the -mfpu and -mcpu options are set as they are. This is important!
Original comment by nightwat...@gmail.com
on 13 Sep 2007 at 4:10
i am having a similar problem here, but building on x86. i built & installed
the
toolchain and copied the hello world source from the wiki. i can build and run
command line C/C++ applications fine. however, building the UIKit hello world
application (objC) doesn't work - running it on iPhone with ./Hello produces a
bus
error. i then created a command line objc application and that works as well.
something must be wrong with the way i am linking against UIKit. i created my
heavenly rootfs by scp'ing stuff over from my phone. is that most likely the
problem?
Original comment by visig...@gmail.com
on 13 Sep 2007 at 6:25
[deleted comment]
i created my heavenly rootfs from the iTunes restore dmg and got the same
result.
that doesn't appear to be the problem.
i also placed some logging in there. the application still seems to load fine,
but
as soon as window = [[UIWindow alloc] initWithContentRect: [UIHardware
fullScreenApplicationContentRect]]; is reached, that is when the bus error
occurs.
Original comment by visig...@gmail.com
on 13 Sep 2007 at 6:57
>>10
This looks like issue 10, which is fixed in the latest SVN.
Original comment by nightwat...@gmail.com
on 13 Sep 2007 at 4:22
Original comment by nightwat...@gmail.com
on 13 Sep 2007 at 4:33
Original comment by nightwat...@gmail.com
on 13 Sep 2007 at 5:05
I never figured out what was wrong, but I deleted everything, and followed the
instructions again from scratch and the toolchain works now.
I can confirm that PPC Mac OSX 10.4 works.
Original comment by d...@linuxprogrammer.org
on 14 Sep 2007 at 3:53
Hmm, ok. Until this can be reproduced I'm setting this to WorksForMe.
Original comment by nightwat...@gmail.com
on 15 Sep 2007 at 2:45
Original issue reported on code.google.com by
d...@linuxprogrammer.org
on 12 Sep 2007 at 11:48Attachments: