Re: [uCsimm] Re: [UCLINUX] Fw: 32-bit PIC patches for the uCsimm !

From: 권석근 (
Date: Thu Jan 06 2000 - 22:26:36 EST

i've seached all uC-libc source tree and header files but i couldn't
find a4 reference in the inline asm. All inline asm use template for
register usage. then, linking user app (32bit-pic) and libc (32bit-pic
would be clean. is this correct Erwin?

-----원본 메시지-----
보낸 사람: Erwin Authried <>
받는 사람: '' <>
날짜: 2000년 1월 7일 금요일 오전 4:43
제목: Re: [uCsimm] Re: [UCLINUX] Fw: 32-bit PIC patches for the uCsimm !

>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
>For a), the linker will give you a message that some offset cannot be
>If I remember correctly, the modules that make problems are crt0.S and the
>exit() function.
>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.
> wrote:
>> Well,
>> Vadim may be right, because there are object format specific loader code
>> the kernel
>> like fs/binfmt_aout.c fs/binfmt_flt.c.
>> My guess: a nessary job for sharing bss/data segment of shared libraries
>> done at this
>> loader file. Is it right? Somebody could explain this correctly but i
>> 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
>> (Doesn't linker resolve all the relocations?)
>> Thanks in advance.

This message resent by the list server

This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:33 EST