Why does the `--oformat binary' option of the gnu linker place the `.data' segment at 0x0200000

Question

I've been writing some "free standing" code for i386 real mode and came across some weird errors while PXE netbooting my code:

PXE-E79: NBP is too big to fit in free base memory
PXE-M0F: Exiting Intel Boot Agent.

after much fiddling with my binaries I isolated it as having any data or code after the

.data

segment marker.

After hexdumping I found that ld moved the instructions all the way to 0x0200000 of all places.

I'm currently generating my flat bin with:

ld --oformat binary

---

Questions:

1. Why does ld do this?

2. Is this specific to the oformat option?

Answer 1

1) The linker probably does this because it felt like it (e.g. possibly for alignment with "2 MiB pages" on 80x86), and because you didn't provide a linker script that says to do anything other than "whatever the linker feels like".

2) I'd assume all output formats do "whatever the linker feels like" (unless the linker is told otherwise).

Note: The actual behaviour may be determined by a default linker script hidden somewhere, and may be "whatever the distribution of the OS felt like" rather than merely "whatever the linker felt like".

In any case, if you want the linker to do something specific, you need to tell the linker specifically what you want by writing a linker script. If you actually have written a "less specific than necessary" linker script then you'd need to make that script more specific.

Answer 2

1-ld use the default linker script. Try -v to see your default 2-Is not specific to the oformat 3-To set another size you must to use -z max-page-size=0x

I tried with 0x100 and 0x1000 and work fine, but 0x500 doesn't.

Salu2 totales