Re: Merging gdc (GNU D Compiler) into gcc

[David Brown <david at westcontrol dot com>]

On 05/10/2011 12:00, Andi Kleen wrote:
> David Brown<david@westcontrol.com>  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