From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28223 invoked by alias); 5 Oct 2011 11:11:25 -0000 Received: (qmail 28203 invoked by uid 22791); 5 Oct 2011 11:11:23 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,TW_GD X-Spam-Check-By: sourceware.org Received: from asav3.lyse.net (HELO asav3.lyse.net) (81.167.37.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 Oct 2011 11:11:08 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by asav3.lyse.net (Postfix) with ESMTP id 2B65A84139; Wed, 5 Oct 2011 13:11:07 +0200 (CEST) Received: from localhost.localdomain (unknown [79.161.10.130]) by asav3.lyse.net (Postfix) with ESMTP id 91958840A1; Wed, 5 Oct 2011 13:11:06 +0200 (CEST) Received: from [192.168.0.60] (helo=[192.168.0.60]) by localhost.localdomain with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1RBPNS-0000Bk-CT; Wed, 05 Oct 2011 13:11:06 +0200 Message-ID: <4E8C3A66.30701@westcontrol.com> Date: Wed, 05 Oct 2011 14:44:00 -0000 From: David Brown User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 Newsgroups: gmane.comp.gcc.devel To: Andi Kleen CC: Andrew Pinski , David Brown , Iain Buclaw , Ian Lance Taylor , gcc@gcc.gnu.org Subject: Re: Merging gdc (GNU D Compiler) into gcc References: <4E8B7D63.3070206@hesbynett.no> <4E8C05C7.6010502@westcontrol.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00072.txt.bz2 On 05/10/2011 12:00, Andi Kleen wrote: > David Brown writes: >> >> Some toolchains are configured to have a series of "init" sections at >> startup (technically, that's a matter of the default linker scripts >> and libraries rather than the compiler). You can get code to run at >> specific times during startup by placing the instructions directly >> within these sections - but it must be "raw" instructions, not >> function definitions (and definitely no "return" statement). > > Note that this only works with modern gcc with -fno-reorder-toplevel, > which disables some optimizations, and is currently broken in several > ways with LTO (in progress of being fixed) > You should not need to worry about re-ordering code within a module unless you have several pieces of code that have to be put into the same "initX" section in a specific order. And if that's the case, then you can just put all that code within the one "naked" function. Of course, you have to put the code in the right section. An example (from the avr-libc documentation) is: void my_init_portb (void) __attribute__ ((naked)) __attribute__ ((section (".init3"))); void my_init_portb (void) { PORTB = 0xff; DDRB = 0xff; } LTO might well remove that function unless you also use the "used" attribute - although hopefully the "Keep" directive in the linker script file will do the same thing. But I can't see why the -fno-reorder-toplevel flag would be needed here. > Normally you don't get any defined order in these sections, both > unit-at-a-time and LTO do reorder. The linker may also in some > circumstances. > You need a linker script that puts these sections in the right place, of course. > So it's somewhat dangerous to rely on. > > -Andi > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29976 invoked by alias); 5 Oct 2011 11:11:39 -0000 Received: (qmail 29962 invoked by uid 22791); 5 Oct 2011 11:11:38 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_00,RCVD_NUMERIC_HELO,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_GD X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 Oct 2011 11:11:25 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RBPNi-00010A-Qq for gcc@gcc.gnu.org; Wed, 05 Oct 2011 13:11:22 +0200 Received: from 79.161.10.130 ([79.161.10.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Oct 2011 13:11:22 +0200 Received: from david by 79.161.10.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Oct 2011 13:11:22 +0200 To: gcc@gcc.gnu.org From: David Brown Subject: Re: Merging gdc (GNU D Compiler) into gcc Date: Wed, 05 Oct 2011 14:59:00 -0000 Message-ID: <4E8C3A66.30701@westcontrol.com> References: <4E8B7D63.3070206@hesbynett.no> <4E8C05C7.6010502@westcontrol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Pinski , David Brown , Iain Buclaw , Ian Lance Taylor , gcc@gcc.gnu.org User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 In-Reply-To: X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00073.txt.bz2 Message-ID: <20111005145900.hBQhTAZvo4nMgHa2nNq0YcJInbhVwaTbUHIVHzdAGm4@z> On 05/10/2011 12:00, Andi Kleen wrote: > David Brown writes: >> >> Some toolchains are configured to have a series of "init" sections at >> startup (technically, that's a matter of the default linker scripts >> and libraries rather than the compiler). You can get code to run at >> specific times during startup by placing the instructions directly >> within these sections - but it must be "raw" instructions, not >> function definitions (and definitely no "return" statement). > > Note that this only works with modern gcc with -fno-reorder-toplevel, > which disables some optimizations, and is currently broken in several > ways with LTO (in progress of being fixed) > You should not need to worry about re-ordering code within a module unless you have several pieces of code that have to be put into the same "initX" section in a specific order. And if that's the case, then you can just put all that code within the one "naked" function. Of course, you have to put the code in the right section. An example (from the avr-libc documentation) is: void my_init_portb (void) __attribute__ ((naked)) __attribute__ ((section (".init3"))); void my_init_portb (void) { PORTB = 0xff; DDRB = 0xff; } LTO might well remove that function unless you also use the "used" attribute - although hopefully the "Keep" directive in the linker script file will do the same thing. But I can't see why the -fno-reorder-toplevel flag would be needed here. > Normally you don't get any defined order in these sections, both > unit-at-a-time and LTO do reorder. The linker may also in some > circumstances. > You need a linker script that puts these sections in the right place, of course. > So it's somewhat dangerous to rely on. > > -Andi >