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

[Bernardo Innocenti <bernie at develer dot com>]

John Lee wrote:
> Bernardo Innocenti, Thanks!
>
> But I am puzzled about what to do next. Can you interpret
> it in more detail? For example, can you tell me which source
> files in GCC,ld,elf2flt & kernel to be modified to support
> shared library on MMU-less ARM?

I don't know for sure since I've not used the ARM much
and never with uClinux.  I think it's better if you
subscribe to the uClinux mailing list (which I've now
added in Cc).


> > For the GCC bits, you may look into the m68k backend.
> > See what's done with the -mid-shared-library option.
> >
> > It's basically PIC code plus an inefficient way to
> > call functions through a fancy variant of the
> > GOT/PLT trick.
>
> I haved searched for "TARGET_ID_SHARE_LIBRARY"(-mid-shared-library
> option flag) in gcc for m68k, and find that the major modification is
> to change the function prologue code to load the GOT pointer with
> correct value.

Correct.


> but I am puzzled about the following question:
>
> 1. If I am right,the changed code will produce the following
> instruction sequence to load the correct GOT pointer in the function
> prologue:
> 	move (a5 - id*4),a5
> Where a5 is the GOT pointer register and the id is the fixed 
> identification number of the current compile unit.

Also correct.  The ID will be 0 for programs and 1, 2, 3...
for libraries.


> How does "move (a5 - id*4),a5" work? In other words, What is the 
> initialization of a5? How the initialization of a5 to be loaded?

It's an array containing pointers to arrays of pointers to functions
and other symbols.  Tricky :-)

Each library/program has its own array of symbols.  The master array
indexes libraries by their IDs.


> 2. The function epilogue code is not changed to restore the
> GOT pointer accordingly,why?

I think it's because all objets must be compiled with the
-mid-shared-library compiler flag so A5 will always contain
the same value everywhere.

Each function reloads it "just in case", perhaps because
it could have been called by another context which doesn't
preserve A5.  (thread entry points, signal handlers, callbacks,
etc.).

It would be more efficient to load A5 once in main() and
leave it there, but then you'd need to explicitly tell
the compiler to reload A5 in a few special functions,
defating the intent of this technique (i.e.: making the
library thing as transparent as possible for maximum
portability).


> > Most of the magic is in the linker, or better, in a
> > shell script disguised as the linker that invokes
> > the elf2flt tool.
>
> If I just modify a shell script disguised as the linker that
> invokes the elf2flt only,which shell script file?

The shell script is in the elf2flt package (see uClinux's
anonymous CVS server) and it's called ld-elf2flt.in when
it's there.  When you run "make install", the old linker
is renamed to m68k-{elf,uclinx}-ld.real and the script
takes its place.

> If I must modify the source files of the linker, which source files?

If arm-nommu uses the FLAT file format too, which I don't know
for sure, you'll probably only need to modify elf2flt.

Otherwise, I think your changes would go in libbfd, the
binutils library that handels binary formats.  The changes
should do something along the lines of elf2flt, i.e.
creating the fancy GOT table needed by -mid-shared-library.


> Is the aim of the modification in the source files of the linker
> to create correct GOT in binary file to support shared library?

Yes.  The Lineo/SnapGear engineers did it in elf2flt for
the m68k, which is quite a kludge, but perhaps much
easier to accomplish externally, so I sympathize with
them :-)


> > Does the MMU-less ARM use the flat executable format
> > or real ELF?
>
> The MMU-ess ARM use the flat executable format.

So you're in luck.  elf2flt already supports multiple
architectures and all you need to do is adding another
one.  This is probably the easiest part.

The hard part is getting GCC's backend to generate
100% PIC code (e.g.: no relocations at all) and
of course doing something along the lines of the
m68k trick with A5 to call functions.



> I have searched the uClinux mailing-list archives with
> keyword "shared lib", but I can not find the questions
> you made several months ago and the answer.
> Can you mail them to me?

Hmmmm... I think I've flushed my maildir folders
once too much, sorry ;-)

I think it was Paul Dale who answered me.  If you want
to search through the uClinux archives properly, I
suggest you download all of it in mbox format and
open it in your favourite editor.  Last time I did it
was over 60MB of text :-)

--
 // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/