gas/ld x86 16-bit 64kb limit and ominous "unreal mode"

[Josef Angermeier]

Hello Etienne

> > Yes, thats probably my choice. - writing a little linker to do exactly
> > that.

>   You can probably use an unmodified ld for that, each time you output
sounds very interesting, because i work this out for my master work
about a extending a pc-bios of a virtual machine (www.faumachine.org)

>  a calll (i.e. far call) you add the current address of the relocation
>  into a special ELF section. At load time you have a small assembler loop
>  to add the current segment load address to each address in your special
>  ELF section. I think that is the usual way to handle relocations for the
>  GNU linker. You just have to consider the relocation as being the segment
>  shifted by 16.
mmm, sounds like you suggest a relocating loader instead of a patched
linker... mmm btw, i don't need dynamic relocation, it's for a
bios-rom, but ok... maybe a good idea... *reading on*

>   If you do not want relocation, you could add a constant (segment << 16)
>  each time you output a call far. That does not hide the 64K segment
>  problem in two cases: comparing pointers may fail when the address
>  pointed is really the same physical address, and you have to decide
>  when to use another code segment (a code segment per function or a new
>  code segment when the next function does not completely fit in the
>  current segment).

Maybe i am wrong but theres another problem you might have forgotten:
how to find out the address of the function in the other segment! - with
"16-bit"-gas + ld you can produce object file with a maximum of 64kb of
code/data because gas quits assigning address after 64kb and doing
partial linking with ld also ends at that limit - i think ... but not
sure.

> > i also wondered about the interrupts' pushing of IP. Concluded that i
> > could maybe change all my bios interrupt handlers to save at first the
> > 'eip' on the stack. Bizarre but probably a solution.
>   The EIP is then the current value - i.e. the content of the interrupt
>  vector. I do not think there is any solution here.

Yes, you are right, was stupid of me.

>   Etienne.
Thanks you
josef