Barry,
I had a similar issue using PRC-Tools, so I e-mailed John Marshall about
it... here is his reply:
> Dear John (I bet you get alot of those ;)
Oh yes... :-)
> I've got a fairly complex application that
> I've been able to compile with 2.0, but I started adding code, and now I'm
> getting this error message.
Is this already a multi-section application? If so, I suspect you are
running
into a problem that Eugene Chin had, but strangely we never seemed to talk
about
it on any of the mailing lists. Here's the email I sent him.
John
====
It's a bug, er, feature, er, limitation in the assembler. The problem is...
a
little difficult to explain. Suppose you have a .c file like this:
int foo() __attribute__ ((section ("foosec")));
int foo() {
big long function... 20K long
}
int bar() __attribute__ ((section ("barsec")));
int bar() {
another function with 20K of code
}
int baz() __attribute__ ((section ("bazsec")));
int baz() {
return foo();
}
Compile this. You get three code sections, each at most 20K. You are
calling
from the start of barsec to the start of foosec, so after linking that jsr
instruction will be something like 'jsr 0(%a2)'. All the code sections are
<
32K, so everything ought to be fine.
However the assembler doesn't know that all those sections actually start at
0
(the linker remaps them to 0 later). As far as the assembler is concerned,
foosec starts at 0, barsec at 20K, and bazsec at 40K. When it assembles the
call from bazsec to foosec, the offset is -40K. Boomo. The assembler calls
this an error: it doesn't know that that linker is going to fix it up to be
smaller later.
To be honest, this problem has always been in the back of my head, but I
haven't
taken the time to think through the implications before. I don't know if it
can
be fixed, but I'll think about it.
You can work around it by splitting up your source code into more separate
translation units. (Maybe just with #ifdef instead of separate files if you
prefer. Compile once with -DFIRST_PART and then again with -DSECOND_PART,
if
you see what I mean.)
----------
For some reason the original error message I included in the message to John
is not in the reply... but John's explanation helped solve the problem.
Basically I compiled each segment of my application independent of the
others so that linker fix ups for the multiple segment application could
happen correctly without the assembler complaining about the >32k jumps.
Ed
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: "Palm Developer Forum" <[EMAIL PROTECTED]>
Sent: Wednesday, September 06, 2000 7:00 AM
Subject: Error: Signed .word overflow; switch may be too large;
>
>
> We are getting this error when using multiple code segments and prc-tools
> 2.0. I got rid of about 20 more by moving code around in our source file
> and tweaking what goes in code segments. We have a bunch of code, so I
> didnt want to post all the code here. It compiles fine under codewarrior.
> What I realized is that we dont understand enough about how the prc-tools
> handle multiple code segments to debug this intelligently. Is there any
doc
> to explain? I am guessing it has to do with the distance from a function
> call to the function. But if they are in different segments, shouldnt that
> be handled for us?
>
> Any insight would be greatly appreciated. Of course I could post the code
> if someone really wants it.
>
>
> GNU C version 2.95.2-kgpd 19991024 (release) (m68k-palmos) compiled by GNU
> C ver
> sion egcs-2.91.57 19980901 (egcs-1.1 release).
>
/prc-tools/H-i586-cygwin32/m68k-palmos/bin/as.exe -mno-68881 -m68000 -l -o
> ibm_
> pab.o C:\DOCUME~1\fijiisle\LOCALS~1\Temp/cc0vcgK2.s
> C:\DOCUME~1\fijiisle\LOCALS~1\Temp/cc0vcgK2.s: Assembler messages:
> C:\DOCUME~1\fijiisle\LOCALS~1\Temp/cc0vcgK2.s:2273: Error: Signed .word
> overflow
> ; switch may be too large; 36598 at 0x7c
> C:\DOCUME~1\fijiisle\LOCALS~1\Temp/cc0vcgK2.s:2307: Error: Signed .word
> overflow
> ; switch may be too large; 36824 at 0xd0
> C:\DOCUME~1\fijiisle\LOCALS~1\Temp/cc0vcgK2.s:2312: Error: Signed .word
> overflow
> ; switch may be too large; 35396 at 0xe0
> make: *** [ibm_pab.o] Error 1
>
> ==========================================================
> Barry R. Beggs, Software Development [EMAIL PROTECTED]
> Phone: (919) 254-2327 T/L
> 444-2327
> IBM - RTP, North Carolina
>
>
>
> --
> For information on using the Palm Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/tech/support/forums/
>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
