DevkitARM: Differences in compiled code Mac OS X vs Windows

support for the ARM toolchain

DevkitARM: Differences in compiled code Mac OS X vs Windows

Postby slaanesh » Sat Jan 16, 2010 3:20 am

:!: I have a curious problem here. I'm compiling code for my GP32 and regularly use both the Mac OS X and Windows releases of devkitARM.
Now the thing is, that the Mac OS X version and Windows versions of the toolchain produce different code - which I find utterly curious.
I would have expected that they produce exactly the same code given the same project.

The bad thing is that the Mac OS X build doesn't produce executable code.

Here's a sample object with the differences marked. I've compiled loads of other working code on the Mac OS X toolchain - in fact that IS my default toolchain. Why would this occur?

For example - gp32snd.o from devkitARMr26 Mac OS X toolchain:
arm-eabi-readelf -s obj/gp32snd.o

Symbol table '.symtab' contains 37 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 FILE LOCAL DEFAULT ABS gp32snd.c
2: 00000000 0 SECTION LOCAL DEFAULT 1
3: 00000000 0 SECTION LOCAL DEFAULT 3
4: 00000000 0 SECTION LOCAL DEFAULT 4
5: 00000000 0 NOTYPE LOCAL DEFAULT 1 $a
6: 00000064 0 NOTYPE LOCAL DEFAULT 1 $d
7: 00000000 0 SECTION LOCAL DEFAULT 5
8: 00000000 0 SECTION LOCAL DEFAULT 6
9: 00000068 0 NOTYPE LOCAL DEFAULT 1 $a
10: 00000090 0 NOTYPE LOCAL DEFAULT 1 $d
11: 00000094 0 NOTYPE LOCAL DEFAULT 1 $a
12: 00000190 0 NOTYPE LOCAL DEFAULT 1 $d
13: 00000000 0 NOTYPE LOCAL DEFAULT 4 $d
14: 00000000 4 OBJECT LOCAL DEFAULT 4 _ZL6buffer
15: 00000000 0 SECTION LOCAL DEFAULT 8
16: 00000000 0 SECTION LOCAL DEFAULT 9
17: 00000000 104 FUNC GLOBAL DEFAULT 1 _Z10soundtimerv
18: 00000000 0 NOTYPE GLOBAL DEFAULT UND __aeabi_unwind_cpp_pr0
19: 00000068 44 FUNC GLOBAL DEFAULT 1 _Z14GpSoundBufStopv
20: 00000000 0 NOTYPE GLOBAL DEFAULT UND GpPcmStop
21: 00000000 0 NOTYPE GLOBAL DEFAULT UND GpPcmRemove
22: 00000000 0 NOTYPE GLOBAL DEFAULT UND GpTimerKill
23: 00000000 0 NOTYPE GLOBAL DEFAULT UND gm_free
24: 00000094 264 FUNC GLOBAL DEFAULT 1 _Z15GpSoundBufStartP10GPS
25: 00000000 0 NOTYPE GLOBAL DEFAULT UND gp32_memcpy
26: 00000000 0 NOTYPE GLOBAL DEFAULT UND gm_malloc
27: 00000000 0 NOTYPE GLOBAL DEFAULT UND gp32_memset
28: 00000000 0 NOTYPE GLOBAL DEFAULT UND GpTimerOptSet
29: 00000000 0 NOTYPE GLOBAL DEFAULT UND GpTimerSet
30: 00000000 0 NOTYPE GLOBAL DEFAULT UND GpPcmPlay
31: 00000000 0 NOTYPE GLOBAL DEFAULT UND GpPcmLock
32: 00000024 4 OBJECT GLOBAL DEFAULT 4 frame
33: 00000020 4 OBJECT GLOBAL DEFAULT 4 soundPos
34: 00000028 4 OBJECT GLOBAL DEFAULT 4 idx_buf
35: 00000004 4 OBJECT GLOBAL DEFAULT 4 shiftVal
36: 00000008 24 OBJECT GLOBAL DEFAULT 4 soundBuf

For example - gp32snd.o from devkitARMr26 Windows toolchain:
arm-eabi-readelf -s obj_win_r26/gp32snd.o

Symbol table '.symtab' contains 39 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 FILE LOCAL DEFAULT ABS gp32snd.c
2: 00000000 0 SECTION LOCAL DEFAULT 1
3: 00000000 0 SECTION LOCAL DEFAULT 3
4: 00000000 0 SECTION LOCAL DEFAULT 4
5: 00000000 0 NOTYPE LOCAL DEFAULT 1 $a
6: 00000064 0 NOTYPE LOCAL DEFAULT 1 $d
7: 00000000 0 SECTION LOCAL DEFAULT 5
8: 00000000 0 SECTION LOCAL DEFAULT 6
9: 00000068 0 NOTYPE LOCAL DEFAULT 1 $a
10: 00000090 0 NOTYPE LOCAL DEFAULT 1 $d
11: 00000094 0 NOTYPE LOCAL DEFAULT 1 $a
12: 00000190 0 NOTYPE LOCAL DEFAULT 1 $d
13: 00000000 0 NOTYPE LOCAL DEFAULT 4 $d
14: 00000000 4 OBJECT LOCAL DEFAULT 4 _ZL6buffer
15: 00000000 0 SECTION LOCAL DEFAULT 10
16: 00000000 0 SECTION LOCAL DEFAULT 8
17: 00000000 0 SECTION LOCAL DEFAULT 9
18: 00000000 104 FUNC GLOBAL DEFAULT 1 _Z10soundtimerv
19: 00000000 0 NOTYPE GLOBAL DEFAULT UND __gxx_personality_v0
20: 00000000 0 NOTYPE GLOBAL DEFAULT UND __aeabi_unwind_cpp_pr0
21: 00000068 44 FUNC GLOBAL DEFAULT 1 _Z14GpSoundBufStopv
22: 00000000 0 NOTYPE GLOBAL DEFAULT UND GpPcmStop
23: 00000000 0 NOTYPE GLOBAL DEFAULT UND GpPcmRemove
24: 00000000 0 NOTYPE GLOBAL DEFAULT UND GpTimerKill
25: 00000000 0 NOTYPE GLOBAL DEFAULT UND gm_free
26: 00000094 264 FUNC GLOBAL DEFAULT 1 _Z15GpSoundBufStartP10GPS
27: 00000000 0 NOTYPE GLOBAL DEFAULT UND gp32_memcpy
28: 00000000 0 NOTYPE GLOBAL DEFAULT UND gm_malloc
29: 00000000 0 NOTYPE GLOBAL DEFAULT UND gp32_memset
30: 00000000 0 NOTYPE GLOBAL DEFAULT UND GpTimerOptSet
31: 00000000 0 NOTYPE GLOBAL DEFAULT UND GpTimerSet
32: 00000000 0 NOTYPE GLOBAL DEFAULT UND GpPcmPlay
33: 00000000 0 NOTYPE GLOBAL DEFAULT UND GpPcmLock
34: 00000024 4 OBJECT GLOBAL DEFAULT 4 frame
35: 00000020 4 OBJECT GLOBAL DEFAULT 4 soundPos
36: 00000028 4 OBJECT GLOBAL DEFAULT 4 idx_buf
37: 00000004 4 OBJECT GLOBAL DEFAULT 4 shiftVal
38: 00000008 24 OBJECT GLOBAL DEFAULT 4 soundBuf
slaanesh
 
Posts: 11
Joined: Tue Sep 15, 2009 2:30 pm

Re: DevkitARM: Differences in compiled code Mac OS X vs Windows

Postby WinterMute » Sun Jan 17, 2010 1:22 am

What happens with r27?
WinterMute
Site Admin
 
Posts: 626
Joined: Tue Aug 09, 2005 2:21 am
Location: UK

Re: DevkitARM: Differences in compiled code Mac OS X vs Windows

Postby slaanesh » Sun Jan 17, 2010 3:16 am

It's the same issue. I tried it with r27 thinking it might have been resolved but the same thing happens.
What does this mean? Why is __gxx_personality_v0 being left out when using the Mac OS X build?

The thing is when I build it I quite literally pop my USB stick out of my Mac, into the Win PC, make clean and make.
And then the same on the Mac - and the builds are different.

I have a similar setup for mipsel-dingux using another toolchain but it produces identical code across Mac OS X and Windows version toolchains - which is what I would expect.
slaanesh
 
Posts: 11
Joined: Tue Sep 15, 2009 2:30 pm

Re: DevkitARM: Differences in compiled code Mac OS X vs Windows

Postby slaanesh » Tue Jan 19, 2010 12:24 am

Hmmm... seems to be something to do with -fno-exceptions
I'll investigate further.
slaanesh
 
Posts: 11
Joined: Tue Sep 15, 2009 2:30 pm

Re: DevkitARM: Differences in compiled code Mac OS X vs Windows

Postby WinterMute » Tue Jan 19, 2010 1:39 pm

Why are you getting C++ name mangling in a compiled C file?
WinterMute
Site Admin
 
Posts: 626
Joined: Tue Aug 09, 2005 2:21 am
Location: UK

Re: DevkitARM: Differences in compiled code Mac OS X vs Windows

Postby slaanesh » Tue Jan 19, 2010 8:56 pm

I'm compiling *.c files with arm-eabi-g++
Specifically setting CC=arm-eabi-g++ and linking with LD=arm-eabi-g++
I also have some assembler routines that I am linking to, these are being declared with extern "C"

Should i be renaming everything *.c -> *.cc ?
slaanesh
 
Posts: 11
Joined: Tue Sep 15, 2009 2:30 pm

Re: DevkitARM: Differences in compiled code Mac OS X vs Windows

Postby WinterMute » Wed Jan 20, 2010 3:00 pm

It's probably best to use .c for C files & .cpp for C++ to avoid confusion. I don't think it's related to your problem since you explicitly use g++ for compiling & linking though.

I really don't know what the issue is unfortunately, could you host the project somewhere & let me have a look. It's been a while since I worked with gp32 though so I'm not sure I'll be able to help. Are you using libmirko or the gamepark libs? If it's the latter then I'll need to find a set of those somewhere too.
WinterMute
Site Admin
 
Posts: 626
Joined: Tue Aug 09, 2005 2:21 am
Location: UK

Re: DevkitARM: Differences in compiled code Mac OS X vs Windows

Postby WinterMute » Wed Jan 27, 2010 9:39 pm

did you get anywhere with this? I'm in the middle of sorting out devkitARM r28, would be nice to get this sorted if it's a problem on my end.
WinterMute
Site Admin
 
Posts: 626
Joined: Tue Aug 09, 2005 2:21 am
Location: UK

Re: DevkitARM: Differences in compiled code Mac OS X vs Windows

Postby slaanesh » Mon Feb 08, 2010 3:56 am

Sorry I can't pinpoint the issue. :-(
slaanesh
 
Posts: 11
Joined: Tue Sep 15, 2009 2:30 pm


Return to devkitARM

Who is online

Users browsing this forum: No registered users and 2 guests