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"


Hello Etienne

>   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.

Ok, principially thats right. In my case, i used the "-Os", optimizing
size option and then gas produced also lots of 16-bit relocs. Didn't
know about that connection before... ok, let's go ahead!

>  You have to set up the linker file to allow different sections all
>  starting at zero (at least code and data).
...
>   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.

Checked it out, you replace the segment-local "function" by stub-code to
switch in the extra-codesegment. - Wow!

>   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.

Yes, i think i'll try that, because the bios-code shall be extendable to
500kb, best 1MB. Because the code shall be compilable without somehow
patched ld/gas i will try to do ld all the address relocation stuff, and
write a post-linker-tool, which patches the call to far calls and the
32-bit addresses to segment:off ones. Hopefully the code/data references
can all be replaced accordingly.

>  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.
Mmm, are you talking about the all-in-one-section-solution or not ? -
where is there a problem ?

>   Another solution may be only indirect inter-segment calls.
You mean using strictly indirect far calls, having a table with the
relocated addresses. I guess, code would then probably relocatable at
runtime...

>   Have fun,
>   Etienne.
Thanks Etienne, have been a great help for me

josef


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