On Thu, Oct 25, 2001 at 06:23:57PM +0530, [EMAIL PROTECTED] wrote:
> My application consists of several code segments. After some recent
> changes, I am getting the well-known "relocation truncated to fit ..."
> error. These error messages are for crt0.o (four times), libcrt.a (six
> times), and libgcc.a (one time).
>
> I thought that this meant the default code section was full. Therefore, I
> move most of the code out of that region. However, I still got the same
> number of errors.
You don't need to guess about the sizes of your sections. You can use
m68k-palmos-objdump -h on your executable and .o files.
> Can somebody please clarify this for me: Are the errors for crt0.o,
> libcrt.a and libgcc.a reported even if another code region (apart from the
> default one) is full?
This could happen if there were a call from the end of the second 32K of
another code section (i.e., if that code section were "over-full") to the
first 32K of the default one. This is not what you are seeing for two
reasons:
1. Non-default code sections are *never* larger than 32K. Thus, you will
never see this message due to a non-default code section being full --
you will always get "region fredres is full" messages.
(There are some who want to be able to have these sections larger,
and there will probably at some stage be a multigen option for that,
but at the moment, unless you have hacked your multigen output, these
sections are limited to 32K and produce only comprehensible error
messages.)
2. crt0.o and libcrt.a are only to do with the startup code (which is all
in the default code section, of course), so any such calls would only
account for the errors to do with libgcc.a.
The only section which can have a size over 32K and be "over-full" is the
default code section. The easiest way to never get "over-fullness" and
"relocation truncated to fit" messages is to limit that section to 32K
in /usr/local/lib/gcc-lib/m68k-palmos/2.95.3-kgpd/pilot.ld. But this is
over-conservative for large applications, which might like to trade
developer pain for more precious default code section space.
The more confusing "relocation truncated to fit" problems in the default
code section are probably due to the startup code. You can reduce these
by moving crt0.o to the middle of the section instead of the beginning.
Do this by linking with --nostartfiles and explicitly listing
/usr/local/m68k-palmos/lib/crt0.o somewhere in the middle of your object
file arguments. (Build-prc will insert a branch instruction into the
code #1 resource to ensure that execution starts in the right place even
if start() is not at the beginning of the resource.)
> P.S.: I use PRC-Tools 2.0 ( Sorry, John, but it's a long story :-) )
Oh, sorry; that solution will not work due to bugs in that version of
prc-tools. Perhaps you should ask Palm for advice, since they claim
to support prc-tools 2.0.
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/