x64 gcc: kernel binary grows up to 1MB

[Guest]

Hi, i have a problem with linking my kernel with gcc x86_x64.
Always when i link my kernel, it grows up to 1MB.
Yeah i read the article in the OS FAQ.
I wrote following linker script but it doesnt help:

Code: Select all

ENTRY(_start)
SECTIONS
{
    .text 0x100000 :
    {
        code = .; _code = .; __code = .;
        *(.text)
        . = ALIGN(4096);
    }

    .data :
    {
        data = .; _data = .; __data = .;
        *(.data)
        . = ALIGN(4096);
    }
    
    .rodata :
    {
       rodata = .; _rodata = .; __rodata = .;
   *(.rodata)
        . = ALIGN(4096);
    }

    .bss :
    {
        bss = .; _bss = .; __bss = .;
        *(.bss)
        . = ALIGN(4096);
    }

    end = .; _end = .; __end = .;
}

I compile my kernel with following flags:
-ffreestanding -nostdlib -fno-builtin -fomit-frame-pointer -m64 -c -fno-zero-initialized-in-bss

Please help.

Thanks in advance.

[mystran]

First of all, what binary format are you linking into?

Is this a raw binary? Or maybe ELF?

You either need a format that allows you to link sections to different locations at link time, or you need to specify where the binary is loaded, that is, what physical address (within file) corresponds to what logical address.

[YeXo]

Where in the faq did you find that linker script?
I think you schould replace this code

Code: Select all

{
    .text 0x100000 :
    {

by this

Code: Select all

{
    . = 0x100000 ;
    .text :
    {

[Guest]

Thanks for your replies !
I tried to change it to:

Code: Select all

. = 0x100000 ;
    .text :
    {

But it still doesnt work.

I forgot to say that I link to ELF.

[Solar]

(I would feel much better if you had a name, other than "Guest". Pick a nick and use it, it makes things easier.)

The error doesn't have to be linker-script-related, it could be caused by your assembler code, or any of the commands you use to compile, assemble, and link your code.

Or, to put it like a computer would do: Insufficient input.

[YeXo]

The error doesn't have to be linker-script-related, it could be caused by your assembler code, or any of the commands you use to compile, assemble, and link your code.

Or, to put it like a computer would do: Insufficient input.

I agree it could by in other places, but if he has errors in het assembler code or in the code to compile or assemble at least one of his intermediate object files should be really big (circa 1mb).

[Solar]

1) Who says it isn't?

2) I'm a bit fuzzy about all the possible permutations of [tt].org[/tt] and -Ttext, but I think I remember having had this "too-big" problem myself some day without ever touching the linker script.

[Candy]

The "too-big" problem is that you insert a whole lot of space because you link something to binary implying a whole lot of space. He doesn't even use binary anywhere, he uses only ELF. That problem can't apply.

It can however be something similar. Does any object file being linked in stand out in size?

[paulbarker]

From the gcc info pages:

`-fno-zero-initialized-in-bss'
If the target supports a BSS section, GCC by default puts
variables that are initialized to zero into BSS. This can save
space in the resulting code.

This option turns off this behavior because some programs
explicitly rely on variables going to the data section. E.g., so
that the resulting executable can find the beginning of that
section and/or make assumptions based on that.

The default is `-fzero-initialized-in-bss'.

You should be able to see whats going on now.

[Guest]

No, every object file has a normal size.
If i don't use `-fno-zero-initialized-in-bss' i still have same problem.

[Solar]

Please provide the command lines used in building (compiler, assembler, linker) as well as a quick list of any .org statements used in your ASM code, so we might be able to reproduce your problem.

I know I'm sounding like a technical helpdesk.

[Guest]

To build the compiler and the linker i followed the instructions in the os faq (http://www.osdev.org/osfaq2/index.php/G ... s-Compiler).

The error doesnt matter on the code.
I compiled:

Code: Select all

int main(void)
{
return 0;
}

Then i linked this code but the elf file was still 1MB.

I also tried to compile without the linker script, just
ld -o bla.elf main.o.
Now the file was OK (about 1.3kb).

Objdump gave me the following informations about the sections:

Code: Select all

test.elf:     file format elf64-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         00000006  00000000004000e8  00000000004000e8  000000e8  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .eh_frame     00000038  00000000004000f0  00000000004000f0  000000f0  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         00000000  0000000000500128  0000000000500128  00000128  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          00000000  0000000000500128  0000000000500128  00000128  2**2
                  ALLOC
  4 .comment      00000012  0000000000000000  0000000000000000  00000128  2**0
                  CONTENTS, READONLY

With the linker script i got (1MB file...):

Code: Select all

test.elf:     file format elf64-x86-64

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         00001000  0000000000200000  0000000000200000  00100000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000000  0000000000201000  0000000000201000  00101000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  2 .rodata       00000000  0000000000201000  0000000000201000  00102000  2**0
                  CONTENTS
  3 .eh_frame     00000038  0000000000201000  0000000000201000  00101000  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .comment      00000fc8  0000000000201038  0000000000201038  00101038  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .bss          00000000  0000000000202000  0000000000202000  00102000  2**2
                  ALLOC
  6 .note.GNU-stack 00000000  0000000000000000  0000000000000000  00102000  2**0

                  CONTENTS, READONLY

Notice that I linked .text to 0x200000 and the output file is still 1MB.

These informations might help.

Thanks in advance.

[Guest]

I played a bit with the starting addresses.
I found out that if i link the elf file to 1MB align addresses such
as 0x100000, 0x200000... the file will be 1MB
If i link the file to 0x200100 i get a 1.32kb output file.

Why ??

[Pype.Clicker]

that seriously looks like a bug in the binutils, if you ask me ... i'd check whether a newer version of binutils for x86-64 is available if i were you...

[Solar]

You "played a bit with the starting address", yet still you do not give sufficient information for us to reproduce the problem. (See my post from May 12th.)

If a toolchain behaves "illogical", then in 99% of all cases it is because you thought you did A, while actually you did B. Others can help you finding the problem, but only if you provide A and B.