From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19518 invoked by alias); 12 Sep 2007 04:10:54 -0000 Received: (qmail 19510 invoked by uid 22791); 12 Sep 2007 04:10:53 -0000 X-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_05,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO X-Spam-Check-By: sourceware.org Received: from 204-133-123-27.dia.static.slbbi.com (HELO mail.chez-thomas.org) (204.133.123.27) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 12 Sep 2007 04:10:49 +0000 Received: by mail.chez-thomas.org (Postfix, from userid 999) id 3A71937C800C; Tue, 11 Sep 2007 22:10:47 -0600 (MDT) X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on hermes.chez-thomas.org X-Spam-Level: Received: from [192.168.1.101] (hermes_local [192.168.1.101]) by mail.chez-thomas.org (Postfix) with ESMTP id 78AB119500CB; Tue, 11 Sep 2007 22:10:43 -0600 (MDT) Message-ID: <46E766C2.3010307@mlbassoc.com> Date: Wed, 12 Sep 2007 04:10:00 -0000 From: Gary Thomas User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: taiyun@sunnorth.com.cn CC: eCos Development Subject: Re: eCos with arm eabi compiler References: In-Reply-To: X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2007-09/txt/msg00000.txt.bz2 taiyun@sunnorth.com.cn wrote: > Dear all: > We are now porting eCos kernel to our platform, EVB named > spaca556g(arm926ej-s). We choose a gcc4.2 eabi > compiler(http://www.codesourcery.com/gnu_toolchains/arm/download.html). The > reason of choosing this compiler is that an EABI compiler can be completely > compatible with ARM RealView libraries. With this arm-eabi compiler, > libraries built from realview can be used. > But there are some problems using this eabi compiler. Because of different > constructing method between arm-elf compiler and eabi compiler, > constructors of global instances can't be invoked automatically when using > the eabi compiler. As a result, we have to make changes to arm.ld and > hal_misc.c files. > > NOTE: arm-elf compiler use .ctor section and 2 labels(__CTOR_LIST__, > __CTOR_END__) to invoke constructors, BUT arm-eabi compiler use .init_array > section and lables(__init_array_start, __init_array_end) > > arm-eabi compiler's linker script has different sections from arm-elf > compiler's, e.g: .ARM.extab, .ARM.exidx and .ARM.attributes 0, these 3 > sections are own in arm-eabi compiler. These sections should be added to > arm.ld, aren't they? If so, there are 2 ways to achieve this goal. One is > making direct changes to arm.ld and adding corresponding sections' > definitions. The other is setting up a new arch-eabi directory in hal/arm, > which is only for arm-eabi compiler. Which is the best? Add a CDL option to the ARM arch which controls this. Then you can have everything be automatic; compiler names (arm-elf-gcc vs. arm-eabi-gcc, etc), linker script, how the constructors are handled, etc. The rest of the code should stay the same; it will still be the same ARM hardware underneath. n.b. if you were to split into an arm-eabi directory, I think there would have to be *way* too much duplication (which inevitably leads to code-rot) BTW, in my mind, this is a development question (hence I changed the mailing list). The eCos maintainer list is for questions/issues dealing with licensing, distribution, etc. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------