gcc-4.8 + ld issue for standalone programs

[christos%astron.com@localhost (Christos Zoulas)]

Background:

Kernels and bootblock typically want to put their startup function at
a specified address (so that the firmware is less complicated and does
not have to find that from the binary header). We typically link those
things using -N which invokes a specific ldscript (which is not the
same as usual binaries; I am not going to explain why here).

With gcc-4.5 all of the code ended up in text segment (for our purposes
here), so by invoking:

        gcc -N -Ttext 0xfooaddress -e barsymbol file-with-barsymbol-first.o ...

We got the first instruction of barsymbol to be at 0xfooaddress.

This now changes with gcc-4.8, because it puts things in other subsections
of .text and those come first in the linker -N description file (typically
machine-type.xbn). Here's an example for the elf_i386.xbn


What happens now is that our symbol does not end in the right place
and we boot garbage:

Possible Solutions:

1. Change the default xbn files to look like:

  .text           :
  {
    PROVIDE_HIDDEN (__eprol = .);
    *(.text .stub .text.* .gnu.linkonce.t.*)
    *(.text.unlikely .text.*_unlikely)
    *(.text.exit .text.exit.*)
    *(.text.startup .text.startup.*)
    *(.text.hot .text.hot.*)
    /* .gnu.warning sections are handled specially by elf32.em.  */
    *(.gnu.warning)
  }

2. Copy the xbn file, make that change and force the build of all the
   boot-blocks and kernels that need this to use the new linker script.

3. Introduce a .text.first section, fix all the linker scripts and all
   the assembly files that contain a startup function to do this.

I prefer (1) since it is the least amount of work.

Any other ideas? Any disadvantages from putting .text first?

christos