This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: 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




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