Mail Archives: djgpp/1996/06/13/12:25:22
From: tome AT theden DOT com
Date: 13 Jun 1996 06:41:02 EDT
I've been combining ansi-C source with AT&T syntax assembler
source using the DJgpp compiler. My question is this:
How can I combine my related sources, which share many functions
between each other, into one object file with only the functions I
specify being available to the linker for use with other object files.
In other words, I have 2 functions that I want to be global for general
use:
initialize_serial_driver(char * buffer, int length)
&
string_from_com_port(char* buffer, length)
but I have other functions that must be called between the C and
assembler code that I don't want to be global after compilation.
Could someone please point me in the general direction of some info on
this or give me some assembler or C directives I should look at, maybe
some gcc or ld command line options.
Basically, what I need to do is combine some object files into one
bigger object file, and I need to be able to specify which of the
functions should be made available to the linker upon linking of this
object file.
Let me recap your question to be ceratin we understand each other: You have a
set of public functions providing a user library service and a set of private
"helper" functions needed by the public functions but which you do not want
client programs to be able to call.
The best way to do this is to place all "C" source functions into a single
source file and declare the private functions "static". For the asm functions
you have two choices: 1) Just do not publish the interface so users cannot know
how to call the functions, or [BETTER] 2) Rewrite them as static "C" functions
using inline asm and place them into the same source file.
Storage class "static" functions have no name scope outside of their
compilation module so users cannot "see" them to call them. Since these
"helper" functions are needed by the interface functions anyway there is no
link-time or run-time memory cost to ganging the source in one file. If the
objects are to be included in a library; link time will be improved as multiple
unresolved references will be satisfied together when the first object is
retrieved from the archive without creating new unresolveds. With the several
functions in separate object modules each object retrieved will add all of the
helper functions it requires to the list of unresolved references causing the
linker to search the symbol table again, increasing link time.
In addition, doing things this way may also allow you to convert any global
storage class variables you have had to create for intra-package coordination
into static storage class thereby relieving name space clutter and avoiding
name clashes with user modules. This last is VERY important to writing bullet
proof user libraries.
--
Art S. Kagel, kagel AT quasar DOT bloomberg DOT com
A proverb is no proverb to you 'till life has illustrated it. -- John Keats
- Raw text -