Page 1 of 1

Odd locations in x86_64-elf binary

Posted: Sat Nov 15, 2014 11:54 am
by eryjus
I have been working with the following linker.ld script successfully for a while: here.

With my VMM/Paging implementation, I am trying to setup recursive paging structures, such as discussed here. So, to make room, I need to move my kernel out of the way. To start this process, I moved the data/bss sections (baby steps). Now my kernel compiles but grub no longer recognizes it.

readelf shows the following:

Code: Select all

$ readelf -e century-64.bin 
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x100168
  Start of program headers:          64 (bytes into file)
  Start of section headers:          74216 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         3
  Size of section headers:           64 (bytes)
  Number of section headers:         8
  Section header string table index: 5

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .boot             PROGBITS         0000000000100000  00002000
       000000000000d485  0000000000000000   A       0     0     4096
  [ 2] .text             PROGBITS         ffffffffc010e000  00010000
       00000000000021af  0000000000000000  AX       0     0     16
  [ 3] .data             PROGBITS         ffff900000000000  00001000
       0000000000000bf4  0000000000000000  WA       0     0     8
  [ 4] .bss              NOBITS           ffff900000001000  00001bf4
       0000000000025000  0000000000000000  WA       0     0     4096
  [ 5] .shstrtab         STRTAB           0000000000000000  000121af
       0000000000000032  0000000000000000           0     0     1
  [ 6] .symtab           SYMTAB           0000000000000000  000123e8
       0000000000002e68  0000000000000018           7   458     8
  [ 7] .strtab           STRTAB           0000000000000000  00015250
       00000000000018b5  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000001000 0xffff900000000000 0x0000000000000000
                 0x0000000000000bf4 0x0000000000026000  RW     1000
  LOAD           0x0000000000002000 0x0000000000100000 0x0000000000100000
                 0x000000000000d485 0x000000000000d485  R      1000
  LOAD           0x0000000000010000 0xffffffffc010e000 0x000000000010e000
                 0x00000000000021af 0x00000000000021af  R E    1000

 Section to Segment mapping:
  Segment Sections...
   00     .data .bss 
   01     .boot 
   02     .text 
I notice that my data/bss sections are now at the beginning of the file, rather than at the end. My linker.ld script has not changed too drastically:

Code: Select all

ENTRY(EntryPoint)
TARGET(elf64_x86_64)

ENTRY_BASE = 0x100000;
CODE_BASE = 0xffffffffc0000000;
DATA_BASE = 0xffff900000000000;

SECTIONS
{
	. = ENTRY_BASE;
	bootStart = .;

	.boot :
	{
		*(.multiboot)
		bootClear = .;
		*(.bootcode)
		*(.bootstack)
		*(.paging)
	}

	bootEnd = .;

	. += CODE_BASE;

	kernelStart = .;

	.text ALIGN(0x1000) : AT(ADDR(.text) - CODE_BASE)
	{
		*(.text)
		*(.rodata)
	}

	. = DATA_BASE;

	.data ALIGN(0x1000) : AT(ADDR(.data) - DATA_BASE)
	{
		*(.data)
	}

	.bss ALIGN(0x1000) : AT(ADDR(.bss) - DATA_BASE)
	{
		*(COMMON)
		*(.bss)
	}

	bssEnd = .;
}
I'm starting to think I have a problem with my cross-compiler build. How would I determine this? Any thoughts on how to correct this?

Thanks in advance for your help.

Re: Odd locations in x86_64-elf binary

Posted: Sat Nov 15, 2014 12:02 pm
by sortie
Can you share your linker command? You may have forgotten to pass -Wl,-z -Wl,max-page-size=0x1000 when linking with your compiler.

Re: Odd locations in x86_64-elf binary

Posted: Sat Nov 15, 2014 12:30 pm
by eryjus
sortie wrote:Can you share your linker command?
Thanks for your quick reply. Here's the whole build:

Code: Select all

$ make -n build
echo Assembling src/kheap.s...
mkdir -p obj
nasm -felf64 -Isrc/ -Iinclude/ src/kheap.s -o obj/kheap.o
echo Assembling src/loader.s...
mkdir -p obj
nasm -felf64 -Isrc/ -Iinclude/ src/loader.s -o obj/loader.o
echo Assembling src/mbcheck.s...
mkdir -p obj
nasm -felf64 -Isrc/ -Iinclude/ src/mbcheck.s -o obj/mbcheck.o
echo Assembling src/pagetables.s...
mkdir -p obj
nasm -felf64 -Isrc/ -Iinclude/ src/pagetables.s -o obj/pagetables.o
echo Assembling src/physmm.s...
mkdir -p obj
nasm -felf64 -Isrc/ -Iinclude/ src/physmm.s -o obj/physmm.o
echo Assembling src/text.s...
mkdir -p obj
nasm -felf64 -Isrc/ -Iinclude/ src/text.s -o obj/text.o
echo Assembling src/virtmm.s...
mkdir -p obj
nasm -felf64 -Isrc/ -Iinclude/ src/virtmm.s -o obj/virtmm.o
echo Linking bin/century-64.bin...
mkdir -p bin
x86_64-elf-gcc -ffreestanding -O2 -nostdlib -z max-page-size=0x1000 -T linker.ld -o bin/century-64.bin obj/kheap.o obj/loader.o obj/mbcheck.o obj/pagetables.o obj/physmm.o obj/text.o obj/virtmm.o -lgcc
I should also mention I am 100% assembly so far.

Re: Odd locations in x86_64-elf binary

Posted: Sat Nov 15, 2014 1:38 pm
by eryjus
OK, I was able to figure it out (at least for now). Ultimately, this was a conflict in the physical locations I was asking the binary to be loaded.

I am page faulting now, but I expected that based on what I have changed (and more importantly, what I haven't).