This is the mail archive of the 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?

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

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

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.

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