ld creates weird flat binary

[felipe]

Hello guys, I'm new in the Forum.

I'm trying to get my first C kernel working, and after trying half a dozen linker scripts that I found in online tutorials I still get a strange kernel flat binary. Then I found this older thread http://forum.osdev.org/viewtopic.php?f= ... 2&start=15 and apparently the command

Code: Select all

ld -T link.ld -o kernel.bin prekernel.o kernel.o

should create the file (the binary came with the zips):

Code: Select all

// hexdump of kernel.bin
00000000  e8 03 00 00 00 f4 90 90  83 ec 0c e8 14 00 00 00  |................|
00000010  83 ec 08 6a 00 68 00 10  10 00 e8 21 00 00 00 83  |...j.h.....!....|
00000020  c4 10 eb fe ba 00 80 0b  00 b8 00 00 00 00 c6 04  |................|
00000030  02 20 40 c6 04 02 0a 40  3d 9f 0f 00 00 76 ef c3  |. @....@=....v..|
00000040  56 53 8b 4c 24 0c 8b 5c  24 10 be 00 80 0b 00 8d  |VS.L$..\$.......|
00000050  04 9b 89 c2 c1 e2 05 80  39 00 74 23 89 d3 80 39  |........9.t#...9|
00000060  0a 75 0b 81 c3 a0 00 00  00 89 da 41 eb 0c 8a 01  |.u.........A....|
00000070  88 04 16 41 42 c6 04 16  0a 42 80 39 00 75 df 5b  |...AB....B.9.u.[|
00000080  5e c3 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |^...............|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000  58 49 58 20 53 79 73 74  65 6d 20 31 39 20 2d 20  |XIX System 19 - |
00001010  56 65 72 73 69 6f 6e 20  70 72 65 2d 41 6c 70 68  |Version pre-Alph|
00001020  61 00                                             |a.|
00001022

which I tested on qemu and works. But using exactly the same command on my system I get the file:

Code: Select all

// hexdump of kernel.bin
00000000  58 49 58 20 53 79 73 74  65 6d 20 31 39 20 2d 20  |XIX System 19 - |
00000010  56 65 72 73 69 6f 6e 20  70 72 65 2d 41 6c 70 68  |Version pre-Alph|
00000020  61 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |a...............|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00100000  e8 62 00 00 00 f4 90 90  b8 00 00 00 00 c6 80 00  |.b..............|
00100010  80 0b 00 20 c6 80 01 80  0b 00 0a 83 c0 02 3d a0  |... ..........=.|
00100020  0f 00 00 75 e8 f3 c3 53  8b 5c 24 0c 8d 14 9b c1  |...u...S.\$.....|
00100030  e2 05 8b 4c 24 08 83 c1  01 eb 22 3c 0a 75 0b 83  |...L$....."<.u..|
00100040  c3 01 8d 14 9b c1 e2 05  eb 10 88 82 00 80 0b 00  |................|
00100050  c6 82 01 80 0b 00 0a 83  c2 02 83 c1 01 0f b6 41  |...............A|
00100060  ff 84 c0 75 d6 5b c3 83  ec 08 e8 99 ff ff ff c7  |...u.[..........|
00100070  44 24 04 00 00 00 00 c7  04 24 00 00 00 00 e8 a4  |D$.......$......|
00100080  ff ff ff eb fe 00 00 00  00 00 00 00 00 00 00 00  |................|
00100090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00101000

which doesn't, obviously. One possible cause is the mismatching versions of tools

I'm using "GCC 3.4.6" and "ld 2.15.92.0.2, 2004-09-27".

And I am using GCC 4.4.3 and ld 2.20.1

I tried to install the versions mentioned but perhaps because they are somewhat old, I couldn't, and besides that would be an inelegant solution.

Any help or pointers would be greatly appreciated.

Felipe R.

[JamesM]

Hi,

If you'll notice, the only difference is the ordering of the code and data sections. The top example has the code first, then data. The bottom has the data first, then code.

The code/data link order is probably not defined correctly in the linker script - or it could be that the original author assumed his string constants would be put in .data when actually on newer compilers they are in .rodata, and the linker script may not contain a rule for .rodata (hence ld defaulting to putting it at the start).

All this is pure conjecture however, as the LD script was not posted

Hope this helps, and welcome.

James

[felipe]

Hi thanks for the reply, but as I said I used the script and the sources supplied and there is another difference, one kernel.bin is about 1MB bigger than the other, you can see from the hexdump addresses. But I will see if adding a .rodata section helps.

anyway here is the script:

Code: Select all

OUTPUT_FORMAT("binary")
ENTRY(loader)
SECTIONS
{
  .text  0x100000 : {
    code = .; _code = .; __code = .;
    *(.text)
    . = ALIGN(4096);
  }
  .data  : {
    data = .; _data = .; __data = .;
    *(.data)
    . = ALIGN(4096);
  }
  .bss  :
  {
    bss = .; _bss = .; __bss = .;
    *(.bss)
    . = ALIGN(4096);
  }
  end = .; _end = .; __end = .;
}

[felipe]

or it could be that the original author assumed his string constants would be put in .data when actually on newer compilers they are in .rodata, and the linker script may not contain a rule for .rodata (hence ld defaulting to putting it at the start).

You got it! I just added a .rodata in the linker script and it works now. Thank you very much.

For documentation the new script is

Code: Select all

OUTPUT_FORMAT("binary")
ENTRY(loader)
SECTIONS
{
  .text  0x100000 : {
    code = .; _code = .; __code = .;
    *(.text)
    . = ALIGN(4096);
  }
  .data  : {
    data = .; _data = .; __data = .;
    *(.data)
    . = ALIGN(4096);
  }
  .bss  :
  {
    bss = .; _bss = .; __bss = .;
    *(.bss)
    . = ALIGN(4096);
  }
  .rodata  :
  {
    rodata = .; _rodata = .; __rodata = .;
    *(.rodata)
    . = ALIGN(4096);
  }
  end = .; _end = .; __end = .;
}

[felipe]

berkus, thanks for the tips. I am new to this notion of a linker script, all I did actually was copy the "data" part and change it to "rodata" without knowing what some commands do. I guess I will figure it out as I use it.