From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28316 invoked by alias); 26 Mar 2008 17:44:49 -0000 Received: (qmail 28301 invoked by uid 22791); 26 Mar 2008 17:44:48 -0000 X-Spam-Check-By: sourceware.org Received: from mgcn1.bloomberg.com (HELO mgcn1.bloomberg.com) (199.172.169.46) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 26 Mar 2008 17:44:30 +0000 Received: from ny2570.bloomberg.com ([172.20.72.138]) by mgcn1.bloomberg.com with ESMTP; 26 Mar 2008 13:44:29 -0400 Received: from ny2528.corp.bloomberg.com (ny2528.corp.bloomberg.com [172.20.85.39]) by ny2570.bloomberg.com (8.14.1/8.14.1) with ESMTP id m2QHiOM8031276 for ; Wed, 26 Mar 2008 13:44:25 -0400 Received: from ny2545.corp.bloomberg.com ([172.20.73.98]) by ny2528.corp.bloomberg.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 13:44:25 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Mar 2008 18:06:00 -0000 Message-ID: From: "Chris Zimman" To: X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: [ECOS] ARM EABI port / static constructor priority removal X-SW-Source: 2008-03/txt/msg00151.txt.bz2 I have a nearly working port of eCos for the Broadcom BCM5890 that also includes ARM EABI (arm-none-eabi-gcc) support. The idea is that people should be able to build eCos with a supported toolchain (aka CodeSourcery) (and perhaps at some point ADS). Redboot builds and runs fine under EABI n= ow (at least on this target, but I suspect it will be OK on other ARM targets = as well). One of the things that's holding it up is the use of __attribute__(init_priority(_pri_))) because there appears to be an issue (I hesitate to call this a bug until it's further understood) where 'ld -r' combines __init_array entry ordering when creating extras.o When you link the resulting target images, the static constructor ordering gets messed up= a little bit, and of consequently things don't work right. Anyhow -- one of the possible solutions that came out of this was to remove the requirement for multiple translation unit static constructor ordering. It's a GNU only extension and generally not considered good behavior. It's a big change, but that by itself is not a good reason not to do it. A= ny thoughts? BTW, this ARM tree has a lot of general improvements. It includes support for ARM processors that don't have the vector tables at 0x0, has a bunch of additional ARM9 helper routines, low power sleep in the idle loop, etc. --Chris -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss