Re: gcc-4.4.x bug in ARM-EABI code generator/optimizer for Objective-C?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


Anyone out there with a hint how to debug/solve this issue?

Tnx,
Nikolaus

Am 09.04.2012 um 12:03 schrieb Dr. H. Nikolaus Schaller:

> Dear help,
> I have built three cross-toolchains that run on Mac OS X and
> cross-compile to i486, arm-eabi, mipsel. The goal is to make
> them compatible to Debian Squeeze.
> 
> Therefore I have gcc-4.4.5, binutils-2.20.1, glibc-2.11.3, linux-headers-2.6.32
> 
> Everything works fine and I was even able to cross-compile
> ARM-Linux-kernels (2.6.32 and 3.2).
> 
> Only one remaining issue is with Objective C.
> 
> As soon as I use the [super method] construct in a method, I
> get this message from the assembler for each class using such
> a super call in any method:
> 
> /var/folders/Q-/Q-r6LiEpG+S3E54UanorqU+++TM/-Tmp-//ccG6BCbh.s: Assembler messages:
> /var/folders/Q-/Q-r6LiEpG+S3E54UanorqU+++TM/-Tmp-//ccG6BCbh.s:164: Error: symbol `_OBJC_CLASS_Test' is already defined
> 
> The really strange thing is that it is
> * only on arm-linux-gnueabi target
> * only for -O1 -O2 -O3 -Os but NOT for -O0
> * by trying all -f options to control the optimizer I could not find a
>  single one that is responsible
> 
> The test code is very simple:
> 
> #define BUG 1
> 
> #include <objc/objc.h>
> #include <objc/Object.h>
> 
> @interface Test : Object
> @end
> 
> @implementation Test
> 
> - (id) init
> {
> #if BUG
> 	[super init];
> #endif
> 	return nil;
> }
> 
> @end
> 
> Compiling with -S option gives me the assembler sources. The i486 and the
> mipsel code looks quite similar (except architecture specific codes and
> variations), but the arm code is quite different.
> 
> It has indeed a second definition of _OBJC_CLASS_Test: and does define
> additional symbols like .LANCHOR1 which is not seen in the unoptimized
> -O0 code.
> 
> I had also built gcc-4.4.7 and there is no difference.
> 
> So is this a known bug in the ARM-EABI code generator/optimizer?
> Is there a workaround by giving some compiler options?
> How can I further debug the issue to find a fix?
> 
> Thanks,
> Nikolaus Schaller
> 
> arm for -O0:
> 
> <Test-arm-linux-gnueabi--O0.s>
> 
> generated assembler code (for -O1):
> arm:
> 
> <Test-arm-linux-gnueabi--O1.s>
> 
> i486:
> 
> <Test-i486-linux-gnu--O1.s>
> 
> mipsel:
> 
> <Test-mipsel-linux-gnu--O1.s>
> 




[Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

Add to Google