You still mean sections, not segments.
Gregg Woodcock <[EMAIL PROTECTED]> wrote:
> OK, now that you've had your fun (which is somewhat deserved), hopefully you
> are willling to help me actually figure out WHY this does nothing for me.
Dude, I have been helping you the whole time. (Meanwhile, you have not
retracted or apologised for your "woefully inadequate" slight.)
> Armed with the map file I can see that indeed, it is now (and actually
> probably was in the beginning) creating a large(r) coderes segment as
> evidenced by these 2 differences:
> coderes 0x00000000 0x00008002
> coderes 0x00000000 0x0000fcd0
Right, so in fact in all probability the thing you were casting
aspersions at was working correctly all along. And happily we're now
going to get on to the real problem.
> The library itself is actually 23080 bytes but the author told me that
> this gets trimmed by the linker (for my type of use) to about 4K (I am
> only using 3 functions out of the 40 or so).
The most likely reason for your problem is that the author is mistaken.
Look at your library with "m68k-palmos-ar tv libfoo.a".
If you see dozens of small .o files, corresponding more or less to the
separate functions in the library, then the linker in prc-tools-m68k
will be able to pull in only the .o files it needs and your executable
will not become bloated with functions you are not using.
If you see only one monolithic .o file, then the author does not know
how to build a Unix-style static library.
> So the REAL problem I am having is that the compiler is including ALL the
> library instead of just the pieces I am actually referencing/using. Perhaps
> I have settings of the linker so that it is not properly discarding unused
> library code?
In Code Warrior, a library is really just an object file. CW uses an
object file format in which functions and function-static data and so on
are stored in separate hunks within the object file. It is this arrange-
ment into separate per-function hunks that allows CW's linker to strip
unused functions and their data from inside an object file.
To the GNU linker, as on Unix for decades, a library is a collection
of object files. If several functions are in one object file, then
they are all smooched together into the same sections. They are not
separable.
The linker used in prc-tools-m68k DOES NOT DISCARD UNUSED FUNCTIONS.
Rather, it only pulls an object file in from a library if that object
file provides a function (or a symbol) required to satisfy the link.
The atomic unit is an object file, not a function [1]. Once an object
file has been pulled in, any unused functions in that object file cannot
be discarded, because there is no way to separate them from the other
functions in the object file.
Thus a badly built monolithic linker library causes the bloating effects
you are seeing.
The GNU linker does in fact support similar behaviour to CW on some
platforms. A combination of GCC's -ffunction-sections flag and the
linker's --gc-sections produces an explosion of separate sections that
provide similar capabilities to CW's object format's hunks. But these
flags are not supported on prc-tools-m68k at this time.
> 1) Is there a way to specify which functions in a library go into which
> segments (remember, all I have is the .h and .a file; it isn't my library)?
> If I modify the .h file with the SECTION_X postfix, will that work?
As noted in the documentation and in the archives many many times,
the SECTION_X annotation needs to be visible (in particular) when the
function to which it refers is compiled. If you annotate the .h file
but do not recompile the .a archive, this will obviously not hold.
No, that will not work.
> 2) Is there way to force the compiler to evaluate which functions are
> actually used BEFORE it stakes out space for them in the codres so that it
> will not consider unused ones?
Have the library built correctly.
John
[1] Well, really the atom is a section within an object file.
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
