This is the mail archive of the
mailing list for the GCC project.
Re: What is needed to support uclinux shared libraries on MMU-lessARM?
- From: Bernardo Innocenti <bernie at develer dot com>
- To: John Lee <chunqiang77 at 163 dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 15 Jun 2004 13:54:05 +0200
- Subject: Re: What is needed to support uclinux shared libraries on MMU-lessARM?
- Organization: Develer S.r.l.
John Lee wrote:
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
Well, they initialize it from the previous value of a5. They
can't initialize it directly to the start of their data
segmente because this would require an absolute address.
Text segments must be free of any absolute reference to
the data segment in order to be shared between multiple
processes and also executed in romfs without loading into
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.
The comment says that lib_main must be used because C code
does the usual trick with A5. The kernel doesn't do anything
special for libraries: the entry point is set to the start
of the text segment. So I still wonder how lib_main gets
Perhaps the program startup code calls lib_main for each
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?
I think elf2flt places the GOT in the FLAT binary right
after the data section, where the BSS should be. The
kernel loads the whole flat file in memory and does all
the relocations into the program text segment and in
the libraries used by the program which are already
"loaded" at that time.
Then the BSS is cleared as usual. If th size of the
relocations exceeded the size of the BSS segment, that
memory is wasted. Well, actually that memory should
still be available for brk(), which is implemented
in uClinux with the restriction that it can only use
the space wasted by the kernel allocator.
The old version of malloc() in uC-libc used
brk() until it ran out of space and then started
allocating new blocks with mmap().
The new kernel page allocator does a better job
than the old 2's power allocator, so this trick
has never been ported to uClibc.
// Bernardo Innocenti - Develer S.r.l., R&D dept.