Both the "old" 16-bit PIC binaries as well as my 32-bit patch use
the same flat format, and both can be converted with coff2flt.
You can even mix 16-bit and 32-bit PIC objects as long as
a) the 16-bit objects have no references to modules that are >32K away,
b) you don't call functions inside 16-bit object modules from 32-bit modules.
For a), the linker will give you a message that some offset cannot be relocated.
If I remember correctly, the modules that make problems are crt0.S and the
Restriction b) is for the moment only because Register a4 is clobbered
inside 16-bit modules in function calls. If the machine description for calls is
modified to use a temporary register for calls, this restriction will be
removed. I tried to add some code, but I got some internal compiler error and gave up.
No big deal for a gcc guru to add this, I suppose.
> Vadim may be right, because there are object format specific loader code in
> the kernel
> like fs/binfmt_aout.c fs/binfmt_flt.c.
> My guess: a nessary job for sharing bss/data segment of shared libraries is
> done at this
> loader file. Is it right? Somebody could explain this correctly but i don't
> know exact mechanizm yet..
> So to make shared library working, both kernel and linker (or compiler it
> self?) must be patched.
> BTW, the msg of "32bit-pic" from Erwin Authried sounds really great!
> and i have a question.
> Mr. Erwin, what the meaning of followng comments?
> you wrote:
> >> There are just a few library-internal calls that
> >> cannot be relocated because the call is made between the start
> >> of the text segment to the end of the text segment where the libraries
> >> are located. When those few calls are fixed.........
> this means that "If i recompile all libraries then it's clean but
> if i do not want to recompile it, then there must be a problem"?
> or "after recompile all libraries, some problems still remained"?
> If your answer is second one, then what is the function which make problems?
> (Doesn't linker resolve all the relocations?)
> Thanks in advance.
This message resent by the firstname.lastname@example.org list server http://www.uClinux.com/
This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:33 EST