Chris DiPierro <[EMAIL PROTECTED]> wrote:
> /usr/local/gnu/m68k-palmos-coff/lib/crt0.o(.text+0x58):crt0.c: relocation
> truncated to fit: DISP16 __reloc_data_for_main
> /usr/local/gnu/m68k-palmos-coff/lib/crt0.o(.text+0x70):crt0.c: relocation
> truncated to fit: DISP16 __do_bhook
> /usr/local/gnu/m68k-palmos-coff/lib/crt0.o(.text+0x8e):crt0.c: relocation
> truncated to fit: DISP16 __do_ehook
This has nothing to do with the math library, it's the infamous 32 KB limit.
The problem is that the beta I have out right now uses John Marshall's binutils
and gcc, which instead of breaking the 32 KB limit only exacerbates the
problem. Explanation: although you can now have multiple code segments and
there is no hard-set limit on the size of any individual segment, the processor
itself still limits 16-bit signed PC-relative displacements, which the coff-
m68k BFD backend calls DISP16, to the range from -32 KB to +32 KB. The messages
that you are getting are thus pretty self-explanatory: some DISP16 relocations
didn't fit.
All simple-minded PalmOS C compilers suffer from this problem, as did all
previous versions of PalmOS gcc. My plans for this version were to add hacks to
the GNU linker to automatically stretch these 16-bit signed references to 32-
bit ones when they don't fit (this has to be done only where necessary, because
68000 doesn't have native support for them and they have to be done with
special instruction sequences, meaning high overhead). The same hacks would
generate the instruction sequences for intersegment references. As explained in
Appendix A of the Programmer's Guide To PalmOS gcc in the current beta
distribution, however, I just couldn't cut it, and had to put out that beta
with John Marshall's binutils and gcc instead. These don't do anything in this
direction and instead have some really ugly hacks in gcc for multiple code
segments, which also exacerbate the 32 KB limit problem by the way they are
coded.
I knew about this problem when I put out the beta, and I honestly documented it
in Appendix A of the manual. I still put out the beta because I thought that I
couldn't really do anything better and what I had was better than nothing, and
as described in the same appendix, I thought that this problem could be worked
around like it has always been: by shuffling code around and inserting jump
islands to maintain -32 KB to +32 KB locality of reference. Only afterwards did
I realize that this miserably breaks the UNIX linking and library paradigm that
the GNU toolchain and my PalmOS gcc programming environment are based on.
Specifically, the linker is designed so that all static libraries are listed at
the end, and the linker pulls in from them only what it needs. Of course this
is in conflict with things like shuffling code around and inserting jump
islands. My PalmOS gcc programming environment heavily utilizes the UNIX
library model. As explained in the full manual, most of the support code has
been made common and placed in the crt library, and specific startup modules
pull in what they need from it. Unfortunately, this exacerbates the 32 KB
limit. The startup code is at the beginning, the code pulled in from the crt
library is at the end, kaboom, and no shuffling or jump islands will help. This
is exactly what you are witnessing. The application crt0 module calls three
functions from the crt library, and in your case all three calls broke the
DISP16 limit.
So what do we do about it? I'm taking one more shot at what I failed before:
adding hacks to the GNU linker to stretch the 16-bit PC-relative references
when they break or when they are intersegment. Right now I'm frantically
hacking on the elf32-m68k BFD backend to implement this. (Yes, I'm switching
from COFF to ELF in the process. There is no technical reason for this except
that the ELF BFD backend is easier for me to hack on than the COFF one. This
means that everything will become m68k-palmos-elf instead of m68k-palmos-coff
and it will say R_68K_PC16 instead of DISP16, as that's what the elf32-m68k BFD
backend calls it. This will also mean a ciao to John Marshall's hacked gcc and
a warm welcome back to Kresten Krab Thorup's nice and clean one.) This time it
looks really promising, and I really hope that this time I will succeed. If I
do, I'll put out a new beta (gamma?).
Stay tuned!
--
Michael Sokolov 2695 VILLA CREEK DR STE 240
Software Engineer DALLAS TX 75234-7329 USA
JP Systems, Inc. Phone: +1-972-484-5432 x247
or +1-888-665-2460 x247
E-mail: [EMAIL PROTECTED] Fax: +1-972-484-4154
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
