[uClinux-dev] Shared libraries

pauli at snapgear.com pauli at snapgear.com
Mon Apr 29 19:30:13 EDT 2002


Hi all,

Stefan Heinzmann wrote:

> I don't know the flat file format, but I dare say that the space
> overhead can be kept very small. It would be enough to group the
> relocation records of each target library together. A relocation record
> would not need to store more than it stored before. It is a different
> question how much programming you'd have to do to implement this --
> there I'm a layman.

Yes this would certainly be possible.  It will require some extra build time 
processing to presort the relocation records etc.  I don't know enough about 
the linker internals to know if a modification is required there.  Currently, 
no linker modifications are necessary and only a very small gcc change.


> I would mind much less here if you stole a few address bits for a
> library id in the GOT pointer. That would allow you to store all
> necessary relocation information in the GOT entry itself, thereby
> avoiding extra storage requirements. That would be less restrictive
> than your scheme: For example it would allow up to 255 *imported*
> libraries with up to 16MB of static storage allocated by *each one* of
> them. And I don't think it would be much harder to relocate on loading
> than what you've got now.

We also use the GOT for procedure calls.  Stealing bits here is pretty much 
the same as stealing them in relocation records...  I guess, one could concoct 
a scheme where this wasn't true...  I'd also wonder about the build 
complexities...


> I agree 100%. I just wanted to point out that it is not *necessary* for
> a shared lib to be pc-relative, i.e. it is not a requirement of the
> dynamic linker. For some processors, that may be important. For the
> Coldfire/m68k it is not. As you rightly point out, you'd probably want
> to stay with pc-rel addressing anyway.

We still support fully relocated executables.
I believe some people are even using them :-)


> Only in the disk file. Since the offset is known at load time of the
> shared library, it needn't be kept in memory after loading it. Just for
> picking nits: Only procedures that access global data will be affected.
> So it's less than one per procedure, in fact.

One small problem, no disc.  The file system on all bar two (?) of our units 
lives in RAM or flash, we execute the code directly from there.  Discs are 
expensive (and huge).  Flash is small.

If we were running from disc, a whole lot of things change.  File size becomes 
much less of an issue as does the number of support utilities etc.  I believe 
that executable images aren't shared properly without an MMU (with a 2.4 
kernel) so shared library aren't going to be a benefit.  Go for fully 
relocatable static executables because they will generally occupy less memory 
and they will execute faster even though they consume considerably more file 
system space.


> Nonono. You've misunderstood something. The import table contains 1
> pointer per shared library. Exceeding 32k offset would mean exceeding
> 8000 loaded libraries. That's way beyond your system's capabilities
> anyway. In my simplistic arrangement, A5 would point to the beginning
> of the application's static data. Addressing static data would use a
> positive offset while addressing the import table takes a negative
> offset. So both have their 32k addressing range. But it needn't be like
> that. You could reserve say 1k for the import table and be left with
> 63k for the static data. That is a system-wide decision, unfortunately,
> but a less stringent one than the the ones in your scheme.

I stand corrected.  I should have thought things through here a bit further :-(


> As you may have guessed by now, the last point convinces me, the others
> don't (yet). Maybe I wound you up by shooting at a solution after it
> was implemented. There you go: You've just presented a long sought
> after solution to a difficult problem that cost you months of sweat and
> blood and just when you sit back and enjoy your success a greenhorn
> comes along and tells you: But this isn't good enough, why didn't you
> do it this or that way?

Actually it took surprisingly little time to implement once we'd worked out 
how we were going to do it ;-)  I suspect my harsh reaction had something to 
do with my feeling more than a little sick yesterday :-(

I'm more than happy to discuss the various possibilities we'd considered along 
the way (and believe me there were plenty).


Regards,

Pauli


This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/



More information about the uClinux-dev mailing list