From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19262 invoked by alias); 26 Mar 2008 18:51:00 -0000 Received: (qmail 19253 invoked by uid 22791); 26 Mar 2008 18:50:59 -0000 X-Spam-Check-By: sourceware.org Received: from londo.lunn.ch (HELO londo.lunn.ch) (80.238.139.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 26 Mar 2008 18:50:42 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1Jeahp-0005yq-00; Wed, 26 Mar 2008 19:50:37 +0100 Date: Wed, 26 Mar 2008 18:56:00 -0000 From: Andrew Lunn To: Chris Zimman Cc: ecos-discuss@sourceware.org Message-ID: <20080326185037.GD5705@lunn.ch> Mail-Followup-To: Chris Zimman , ecos-discuss@sourceware.org References: <20080326180616.GA5705@lunn.ch> <20080326181817.GB5705@lunn.ch> <20080326183202.GC5705@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) 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: Re: [ECOS] ARM EABI port / static constructor priority removal X-SW-Source: 2008-03/txt/msg00159.txt.bz2 On Wed, Mar 26, 2008 at 02:38:29PM -0400, Chris Zimman wrote: > > So back to my original question, what is your concept for replacing > > them with something else. How are you going to ensure things happen in > > the right order. > > One possibility is to put them all in one translation unit. They are > constructed in the order that they appear, although that's kind of a big > kludge. Agreed. So lets forget about that. > Another is to add explicit initialization calls to the various bits to invoke > the constructors at runtime. Also ugly. You break the nice packing model. Say i have an out of tree package, a device driver for the wall clock on my hardware. The current code allows my code to have a static initializer with priority that is after I2C is up and running and it is totally independent of the in tree code. I don't need to modify the in tree code at all. The linker sorts it all out. Your suggestion would force me to modify the in tree list of constructors. The same could be said for application code. My application wants a static constructor called after the OS is up an running, but before main() is called. Should i modify the OS to list my application constructors? Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss