Link script producing huge binary

[duran]

Hi,

I'm trying to assemble a simple kernel, based off Brans tutorial. the sources assemble/compile fine, however once ld is run, i am left with a 1.1MB kernel image.

Here is the full link script in use:

Code: Select all

OUTPUT_FORMAT("binary")
ENTRY(start)
phys = 0x00100000;
SECTIONS
{
   .text phys : AT(phys) {
      code = .;
      *(.text)
      *(.rodata)
      . = ALIGN(4096);
   }

   .data : AT(phys + (data - code))
   {
      data = .;
      *(.data)
      . = ALIGN(4096);
   }
   .bss : AT(phys + (bss - code))
   {
      bss = .;
      *(.bss)
      . = ALIGN(4096);
   }
   end = .;
}

There are 3 object files (boot, main and vga), which all compile/assemble cleanly and produce sub-4k objects. I assume it's something wrong in the link script, but i could be wrong, not fully understanding it and all (sub-question, can anyone point to some good sources regarding the use of ld?)

Please help

[Solar]

LD -> Linker Scripts -> GNU binutils docs.

Also, Bran's Known Bugs.

Hint: There's only one thing in the linker script that could result in a >1MB binary, given sub-4k input:

Code: Select all

phys = 0x00100000;

I.e., your assembler and your linker disagree about what needs to be done with the object code.

[duran]

I had not seen that wiki page. Thank you.

I managed to solve it earlier when I noticed that I was using a.out rather than ELF, a change I'd inadvertantly made thanks to skimming over some of the bootloader stuff, somehow aout registered itself in my head as ELF. I then changed it back to a.out later after I noticed my mistake, which I guess is when I introduced this problem.

Going off what the wiki says, is this some problem with null termination on strings causing the linker to screw up the rodata section? or something else?

[Solar]

Going off what the wiki says, is this some problem with null termination on strings causing the linker to screw up the rodata section?

No.

GCC places string constants in a section of the object file called .rodata. At the point when the wiki page was written, Bran's linker script did not include that section into the kernel binary. I.e., printing character constants (which reside in the .data section) did work, printing string constants (residing in the - unlinked - .rodata section) did not. Apparently, Bran had that one fixed at some point.

The point of me linking that page was that, if you actually discovered an error in Bran's tutorial, that (aside from a mail to Bran in person) would be a good place to write about it so others might benefit from your work.

[Velko]

Most likely problem is caused by LD padding the file up to your Load address. So you end up with 1 MiB of padding and 0.1 MiB of actual kernel.

Adding -n switch to LD command might help.

[duran]

GCC places string constants in a section of the object file called .rodata. At the point when the wiki page was written, Bran's linker script did not include that section into the kernel binary.

He does include it now, and the problem still exists with it included. I'm still trying to grasp exactly what is causing this, and why it only occurs with a.out binaries. It seems plausible that ld is padding the binary with the 1MB, although given that .text was included at phys (1MB), one would expect the first 1 meg of the file to be zerofill. A glance at the binary in a hex editor proves this is not so. the zerofill comes after some code, although I didn't spend much time deciphering exactly what the code content was. I shall revisit this and see if I can identify, if it will help.

[duran]

I don't know. It was part of Bran's script, and I left it alone. I'll investigate this.