Re: gcc-4.8 + ld issue for standalone programs

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

In article <la7b82$paq$1%ger.gmane.org@localhost>,
Christos Zoulas <christos%astron.com@localhost> wrote:
>
>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

the original xbn file looks like:

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


>
>
>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
>
>