0

I have this linker script for my elf executable:

ENTRY(_start)

SECTIONS
{
    . = 0x500;

    .mboot BLOCK(4K) : ALIGN(4K)
    {
        *(.mboot)
    }

    . = 0x7E00;

    .ap_stack BLOCK(48K) : ALIGN(4K)
    {
        *(.ap_stack)
    }

    .mp_entry BLOCK(4K) : ALIGN(4K)
    {
        *(.mp_entry)
    }

    _mp_entry_end = .;

    . = 1M;

    .init BLOCK(4K) : ALIGN(4K)
    {
        *(.init)
    }

    _init_end = .;

    . =  0xFFFFFFFF80000000 + _init_end;

    .text : AT(ADDR(.text) - 0xFFFFFFFF80000000)
    {
        _code = .;
        *(.text)
        *(.rodata*)
        *(.stack)
        . = ALIGN(4096);
    }

   .data : AT(ADDR(.data) - 0xFFFFFFFF80000000)
   {
        _data = .;
        *(.data)
        . = ALIGN(4096);
   }

   .eh_frame : AT(ADDR(.eh_frame) - 0xFFFFFFFF80000000)
   {
       _ehframe = .;
       *(.eh_frame)
       . = ALIGN(4096);
   }

   .bss : AT(ADDR(.bss) - 0xFFFFFFFF80000000)
   {
       _bss = .;
       *(.bss)
       *(.rodata)
       *(COMMON)
       . = ALIGN(4096);
   }

   _end = .;

   /DISCARD/ :
   {
        *(.comment)
   }

}

Which should place section .ap_stack at physical/virtual address 0x8000. In assembly, I have:

[BITS 32]
section .ap_stack, nobits
align 16
ap_stack:
resb 0x48000
ap_stack_top:

which should make an empty space at that point, however, if I check final elf, I get:

Idx Name          Size      VMA               LMA               File off  Algn
  0 .mboot        0000000c  0000000000001000  0000000000001000  00001000  2**12
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .mp_entry     00000001  000000000000c000  000000000000c000  00002000  2**12
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .init         00006054  0000000000100000  0000000000100000  00003000  2**12
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .text         0000efa0  ffffffff80106060  0000000000106060  00009060  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  4 .data         00001000  ffffffff80115000  0000000000115000  00018000  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  5 .eh_frame     00002000  ffffffff80116000  0000000000116000  00019000  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .bss          00012000  ffffffff80118000  0000000000118000  0001b000  2**5
                  ALLOC
  7 .stack,       00005000  ffffffff8012a000  000000000012a000  0001b000  2**4
                  ALLOC, READONLY
  8 .ap_stack,    00048000  ffffffff8012f000  000000000012f000  0001b000  2**4
                  ALLOC, READONLY
  9 .debug_info   000097b8  0000000000000000  0000000000000000  0001b000  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_abbrev 0000210d  0000000000000000  0000000000000000  000247b8  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_aranges 00000560  0000000000000000  0000000000000000  000268c5  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_line   000030e7  0000000000000000  0000000000000000  00026e25  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_str    000026a5  0000000000000000  0000000000000000  00029f0c  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_ranges 000001b0  0000000000000000  0000000000000000  0002c5b1  2**0
                  CONTENTS, READONLY, DEBUGGING

because linker has moved my ap_stack to be together with stack, which is definitely what I don't want. Any reason why and how can I stop this behavior?

Enerccio
  • 257
  • 1
  • 10
  • 23
  • Since _nobits_ sections doesn't take up any space in file, I believe all of the _nobits_ sections are added in the order they are first encountered but are placed after the last _progbits_ section. – Michael Petch Dec 25 '15 at 01:05
  • Not related to your problem but `resb 0x48000` appears wrong. maybe you meant `resb 48*1024` – Michael Petch Dec 25 '15 at 01:07
  • @MichaelPetch actually ld script is wrong, I want 0x48000 bytes – Enerccio Dec 25 '15 at 01:09
  • @MichaelPetch how can I add a writeable section before that? If I remove nobits or even use alloc, write or any combination, it gets moved, and I need to be able to write to those sections. If it gets moved, then I end up with entry.s:(.mp_entry+0x25): relocation truncated to fit: R_X86_64_32 against `.ap_stack,' – Enerccio Dec 25 '15 at 01:11
  • @MichaelPetch, no I am trying to use location that should be within first 32bit, if the section does not get moved. I reference ap_data, which should be at address 0x7E00, but linker moves it past .stack, putting it at some high address above 0xFFFFFFFF80000000 which then obviously fails to use. I need to stop linker moving my sections as it pleases, because I need them in order it is. – Enerccio Dec 25 '15 at 01:40
  • the (.stack) will have attributes for .read+.write. however, the (.text) will have attributes of .prog. These are conflicting, so the linker moved the .stack out of the .text section – user3629249 Dec 29 '15 at 03:45
  • the linker command file seems to be missing the `memory` statements – user3629249 Dec 29 '15 at 03:49
  • these lines: ` . = 0x500; .mboot BLOCK(4K) : ALIGN(4K)` will result in a skipped area of approx. 3.5k bytes – user3629249 Dec 29 '15 at 03:51
  • in general, the best method is to give each type (.data, .text, etc) into a .section of the same name. however, different types that have different attributes (readonly, etc) should not be mixed in the same .section of the linker command file. – user3629249 Dec 29 '15 at 04:19

0 Answers0