LD padding binary to entry point

zerosum · Post by **zerosum** » Thu Apr 10, 2008 11:19 pm

Hi all,

I thought I'd make a couple of new threads, since my original one is going a little off topic.

I have two linkers (ld) on my system. One is native, one is a "cross-linker."

When I link a binary with the native linker, using the -Ttext 0x100000 flag, it does the sensible thing and sets the virtual starting address to 0x100000.

When I link a binary with the "cross-linker" using the same -Ttext 0x100000 flag, it pads out the resulting binary so that the .text section doesn't start until offset 0x100000 in the file.

This is just odd and it's irritating. I'm having to gzip my main kernel so that it fits on my floppy image and thus can be booted!

Does anyone know why it's doing this and how I can fix it?

Thanks in advance,
Lee

JamesM · Post by **JamesM** » Fri Apr 11, 2008 1:22 am

yeah, don't use a raw binary output format. It doesn't have any headers so the only way the linker can ensure something is loaded at a specific address is to pad it from zero.

Use ELF or PE.

zerosum · Post by **zerosum** » Fri Apr 11, 2008 1:41 am

Thanks James

Sorry if I wasn't clear, but I'm not using raw binary output, I'm generating an elf64.

Cheers,
Lee

JamesM · Post by **JamesM** » Fri Apr 11, 2008 1:43 am

Post your linker script and link lines?

zerosum · Post by **zerosum** » Fri Apr 11, 2008 1:55 am

I had been using the one from your tutorial

At the moment I'm just adding the linker flag -Ttext 0x200000. The reason it's 0x200000 is that I've got a 32-bit kernel stub being loaded in at 0x100000 which will (eventually) load the 64-bit kernel into memory, set up long mode and jump into said kernel.

So basically ld is getting this:

ld -o kernel (objects) -Ttext 0x200000

That's it. It's basically padding the elf64 out to whatever I said the text virtual address to. Mind you, if I don't set the text virtual address, I don't get a padded binary BUT ld seems to pick an arbitrary virtual address and so my kernel ends up getting loaded at like the ~6mb mark.

Cheers,
Lee

JamesM · Post by **JamesM** » Fri Apr 11, 2008 1:57 am

So you don't give it a linker script. Hmm. There's your problem. Have a delve into the /lib directories of your crosscompiler install and have a look at the default x86_64 linker script. That's probably where the difference will be.

zerosum · Post by **zerosum** » Fri Apr 11, 2008 2:08 am

I don't think that's the issue either

If I use the linker script provided in your tutorials, but change the text virtual address to 0x200000, the same thing happens; ld still pads it.

Cheers,
Lee

JamesM · Post by **JamesM** » Fri Apr 11, 2008 2:16 am

zerosum wrote:I don't think that's the issue either

If I use the linker script provided in your tutorials, but change the text virtual address to 0x200000, the same thing happens; ld still pads it.

Cheers,
Lee

Do you change the text virtual address in the script, or on the command line?

zerosum · Post by **zerosum** » Fri Apr 11, 2008 2:19 am

In the script

I was using the script, but then I had issues with padding so I stopped and tried just using command-line arguments. Using the script or not, I get padding to the entry point.

This only happens when I'm outputting elf64; elf32 is fine. It's odd

Cheers,
Lee

Laksen · Post by **Laksen** » Fri Apr 11, 2008 3:53 am

The standard bfd for elf64 is elf64-x86_64. Try using elf64-little instead

zerosum · Post by **zerosum** » Fri Apr 11, 2008 5:29 am

Perfect, that did it

Thanks Laksen, I much appreciate it ;-D

Cheers,
Lee