This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: What is needed to support uclinux shared libraries on MMU-lessARM?
- From: "John Lee" <chunqiang77 at 163 dot com>
- To: gcc at gcc dot gnu dot org <gcc at gcc dot gnu dot org>
- Cc: bernie at develer dot com <bernie at develer dot com>
- Date: Tue, 15 Jun 2004 10:7:12 +0800
- Subject: Re: What is needed to support uclinux shared libraries on MMU-lessARM?
Bernardo Innocenti,
>>>If you meant that nobody knows about it, well all the
>>>people who made the current ARM and m68k toolchains
>>>for uClinux are active posters in uclinux-dev and
>>>they helped me a lot with my m68k work.
>>
>> I am sorry for my poor English. I mean that nobody
>> reply to my question in uClinux-dev mail list.
>
>:-) English is not my native language too,
>otherwise I would probably have understood you
>the first time.
>
>
>>>>1. In function main() of the application, what is the
>>>>first value of a5? Who load the initialization of a5?
>>>
>>>Look for get_pic_a5() in linux-2.4.x/arch/m68knommu/platform/5307/signal.c.
>>>For 2.6, I dunno where they've hidden it ;-)
>>
>> According to the source code in linux-2.4.x/arch/m68knommu/platform/5307/signal.c
>> and in linux-2.4.x/arch/m68knommu/platform/5307/entry.S, Before the program return
>> from system call, get_pic_a5() will be called to get the value of a5. Is it right?
>
>Yes. And I believe (but I'm not sure) that this is how A5 gets
>its initial value when the task execution starts.
>
>Signal handlers also require A5 initialization because they
>could be called from anywhere, even from places where A5 is
>being used for other purposes.
>
>
>>>For libraries, there's also an additional trick in the
>>>startup code:
>>>
>>>/* We've got to provide an entry point that doesn't stuff around with a5 like
>>>* C routines tend to do. We must also setup a5 from d5 which won't point to
>>>* this libraries data segment but from which it can be obtained.
>>>*/
>>>asm( ".globl lib_main\n\t"
>>> ".type lib_main,@function\n"
>>> "lib_main:\n\t"
>>> "move.l d5, a5\n\t"
>>> "bra.w main\n"
>>> ".L__end_lib_main__:\n\t"
>>> ".size lib_main,.L__end_lib_main__-libmain"
>>>);
>>>
>>>This is in uclinux/lib/libc/main.c, but uClibc also links
>>>this file when it's built as a shared library (see uClibc's
>>>top-level Makefile).
>>
>>
>> Who calls function lib_main()? If nobody calls it, these code
>> will not work in any case.
>
>That's a good question, but I don't know the answer.
>
>binfmt_flat.c does some special things for libraries, but
>there's nothing about lib_main or passing something in D5.
>I've grepped the kernel looking for the place where D5 is
>initialized, but I couldn't find it.
>
>There's no ld.so in uClinux (at least, not for uClibc),
>so I'm completely lost :-)
>
>Paul Dale probably know the answer...
I don't think that the kernel have to initial d5 or a5 because
every function(!current_function_is_leaf) in each library will initial
a5 itself.
At first I think these source codes trick the linker to create an entrance
for each library, but function main() in main.c is enough to do this.
so I'm lost too, I will try to get the answer in uClinux-dev maill list.
And I have a question about the linker yet:
As we know, the high 8 bits of each item(32 bits) in GOT will identify
the id of the target library, But how the high 8 bits of each item in GOT
is set in the linker?
Thanks and Regards
John Lee