Re: What is needed to support uclinux shared libraries on MMU-lessARM?

[Bernardo Innocenti <bernie at develer dot com>]

John Lee wrote:
> Bernardo Innocenti,
> > > 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.

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
RAM.


> 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
executed.

Perhaps the program startup code calls lib_main for each
library?


> 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.
\X/  http://www.develer.com/