Mr. Dresner,
Just a few notes to your excellent and carefully thought out reply:
> 1. As you noted, this adds nearly a megabyte per module. While
> this isn't much with today's systems when you're adding just
> one module, we
> have systems that have our drivers modularized into as many as 8-10
> different modules. If I included the whole library with each one that
> needed it (about half), then we'd have 4-5 MB of library
> choking a 64 MB
> system when we only need, maybe, 25 KB total.
That is perfectly understandable in memory restricted systems with
lots of modules loaded. In such systems, the careful selection scheme
obviously makes sense as an optimization.
Actually, I just did a test of my module with and without libgcc.a
(leaving the externals unresolved). The difference was a whopping 14 KB. I
think ld is taking care of selecting only the required modules for linkage.
It is not obvious that careful hand selection will do any better.
> I would not
> deprecate loading
> the whole library (but see #2 below) if there was an easy way
> to make the
> functions (or at least some of them) in the library
> "external" in the kernel
> once the library was loaded so I didn't have to include
> multiple copies of
> it.
Though they may not be reentrant, so such a mechanism might not be
safe.
>(There is a way using a script for the loader, but it's
> quite esoteric
> and can't be maintained by lower level personnel after I move
> on to the next
> project [or retire].)
One of the best reasons not to use it.
> 2. In the Intel implementation (the one I'm familiar with) the
> entire gcc-library is "self-contained" but there are other
> architectures
> (Alpha has come to light recently) in which various functions
> in the library
> have links to I/O functions (sprintf and fputs come to mind)
> for writing
> diagnostics.
This is not true. A quick dump with 'nm' will show that even the
generic Intel libgcc.a has references to fprintf, fopen, fclose, malloc,
etc. within. Thus all of the libgcc.a libraries share this "defect".
> Even if the specific modules needed by your driver
> don't reference them directly or indirectly, loading that library
> linked with the driver would then require either a module of stubs
> to satisfy these extraneous external references or linking in
> another (dangerous) library.
This is not true either. An nm dump of my module when linked with
libgcc.a shows no references to any of the illegal functions listed in my
previous paragraph. The only way I can explain the behavior seen by others
(under Alpha or whatever) is if either:
1) The linker in the Alpha binutils works very differently with static data
(unlikely)
2) I am flipping some switch they are not flipping on my ld command line
(unlikely)
3) They are confused as to which library is causing the problem. Both libm
and libc will cause these problems.
> There's one more reason that I don't mention very often:
> 3. It has happened (to me when I was including the
> whole library)
> that I referenced the name of a function which happened to be
> in the library
> and which duplicated a name I was going to use (for good
> reason) and which
> then forced me to either change the name in several files or
> to link in just
> the stuff from the library I needed.
I would probably have renamed the function to save myself a load of
pain in sifting through the library myself. Renaming would also prevent any
future confusion on which function is actually used (unlikely, but
possible). With just about any modern editor renaming all instances of the
function is pretty painless.
> B. Finding the gcc library
> There are a couple of more ways too. I didn't think
> that mine was
> that convoluted and that it was likely to change, although
> yours is slightly
> more portable between architectures if that's a
> consideration, though I
> could probably make the output of find do what gcc does in
> your method.
> (Portability of drivers to different architectures usually
> isn't a concern
> for most of us using rtlinux.)
Asking gcc also works in cross-development environments or
multiple-kernel environments. We have several machines around here with
more than one version of gcc installed and a simple find from / will find
many libgccs. If you simply ask the compiler you are using where it is
finding its libgcc, you will always get the right answer. Thus my comment.
> C. I can't (at least not off the top of my head) think of a
> way to have the
> Makefile perform a recursive extraction of modules from the
> library in the
> case that one needed module then required another module from
> the library.
> Also, while I haven't run into the situation yet, there is
> (always) the
> possibility that an external reference is not in a module of
> the same name;
> while there might be an automatable way to handle this, it
> could get really
> ugly really quickly.
Grab the output from insmod and check it for undefined external
references. Use nm to see if they exist in libgcc.a. If they do, use ar to
extract them and add them to a locally generated library and rebuild things.
I, personally, do not want to write the Perl or Tcl script to do this, but
it should be fairly straight forward.
Of course, my findings with regard to the added size of linking
against the library seems to make the point moot for me (and most users, I
would imagine).
Regards,
Steve
--------------------------
Stephen D. Cohen
Engineering Manager
Xybion Sensor Positioning Systems
11528 53rd Street North
Clearwater, FL 33760
Voice: (727) 299-0150
Fax: (727) 299-0804
[EMAIL PROTECTED]
www.xybion.com
************************************************************************
THIS EMAIL, AND ANY ATTACHMENTS, CONTAINS CONFIDENTIAL AND PRIVILEGED INFORMATION
INTENDED FOR THE USE OF THE ADDRESSEE. IF YOU ARE NOT THE INTENDED RECIPIENT OR AN
AUTHORIZED REPRESENTATIVE OF THE RECIPIENT, DO NOT READ OR DISTRIBUTE THE CONTENTS OF
THIS EMAIL AND DELETE IT FROM YOUR SYSTEM. THIS EMAIL AND ALL ATTACHMENTS HAVE BEEN
SCANNED FOR VIRUSES AND ARE BELIEVED TO BE VIRUS FREE. HOWEVER, IT IS THE RECIPIENT'S
RESPONSIBILITY TO ENSURE THAT THEY ARE VIRUS FREE. XYBION DOES NOT ACCEPT ANY
RESPONSIBILITY FOR ANY LOSS OR DAMAGE ARISING IN ANY WAY FROM USE OF THIS EMAIL AND
ATTACHMENTS. XYBION ALSO DOES NOT ACCEPT RESPONSIBILITY FOR PERSONAL EMAIL OR EMAIL
NOT ASSOCIATED WITH ITS BUSINESS PURPOSES.
************************************************************************
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/
