This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: gas/ld x86 16-bit 64kb limit and ominous "unreal mode"
- From: Etienne Lorrain <etienne_lorrain at yahoo dot fr>
- To: Josef Angermeier <sijoange at cip dot informatik dot uni-erlangen dot de>
- Cc: binutils at sources dot redhat dot com
- Date: Thu, 30 Jun 2005 14:29:01 +0200 (CEST)
- Subject: Re: gas/ld x86 16-bit 64kb limit and ominous "unreal mode"
--- Josef Angermeier <sijoange@cip.informatik.uni-erlangen.de> wrote:
> > It is possible to use "far" pointer for the code using
> > segment:offset pair and transforming all call and ret by calll and
> > retl, but your executable
>
> 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
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.
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).
> > You can also use 32 bits code
> > address, but _only_ with interrupt disabled, and without any
> > exception (like division by 0 or division overflow) possible: such an
> > interrupt will save on the stack a 16 bits segment and a 16 bits
> > offset, so no return possible to the interrupted treatment because
> > the MSB of the offset is lost...
>
> 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.
Etienne.
___________________________________________________________________________
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com