This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


--- Josef Angermeier <sijoange@cip.informatik.uni-erlangen.de> wrote:
> >   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.

  GAS does not care of the address of functions, it just emit a "near long"
 or "far short" call with a relocation in the object file with a 32bits
 relocation field.
 The linker deals with these relocations, and may leave some of them to
 be resolved by the loader. The loader in our case may be at run time or
 simply objcopy generation a binary file.

 Nothing checks for 64 Kbytes segments, but a possible:
MEMORY { ram : ORIGIN = 0, LENGTH = 64K }
 in the linker file. Having relocation over 65536 may be bad in some
 cases - we are using little endian relocation so that still works -
 but do not bother the wrong people if you have a problem (i.e. you are
 completely on your own).
 You have to set up the linker file to allow different sections all
 starting at zero (at least code and data).

  The linker emit a relocation per "call*", this relocation value will
 contain the address of the function. You cannot call in another %cs
 section without exactly knowning what you are doing, i.e. what is
 the relocation offset in this segment.
  You should look at the boot.ld file of Gujin, with the LD and GAS manual
 in front of you. There is two (or three) code segment with few inter
 segment calls.

  A really clean solution for calll (i.e. call far) would probably be to
 add another kind of relocation adjusting the linear address to a
 segment:offset pair (to use only for far call and indirect far call),
 and put all the code in the same section (of max 640 Kbytes), but I did
 not need that for Gujin.
 This solution may smell bad if you have two relocation at the same place
 (addition not possible), but most of the time you will only add on segment
 and substract on offset. I do not know, that could probably work.

  Another solution may be only indirect inter-segment calls.

  Have fun,
  Etienne.


	

	
		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]