Hello Ed,
Thanks for posting Johns reply.
I have found that in the archives meanwhile and tried re-arranging my
functions.
I was hoping that the jump distances reduces with this re-arrangement but
nothing happend.
The error messages is ALWAYS reporting a distance of 33822 bytes regardeless
what I'm doing.
Meanwhile I have re-arranged my entire code but nothing changed to this
situation.
I still have a very large portion of coding in front of me so I'm realy
worrying that this will block me from making that program.
How have you (or any other developer listening) got out of this problem?
Anybody who can explain the process of compiling? Are the functions compiled
in sequencial order of the source file or in the order of their usage (or
completely different).
Anybody who knows the inside of this compiler/assembler/linker can you
please try explaining the logic that runs behind this compilation process?
Maybe this can help me understanding better what to change. Thanks a lot.
Thanks
Ole
M. Edward Wilborne III <[EMAIL PROTECTED]> schrieb in im Newsbeitrag:
[EMAIL PROTECTED]
>
> Ole,
>
> Here is a message I got from John Marshall that explains what I think is
> happening to you. It was happening with me as well (I was using VFDIDE,
and
> PRC Tools v2.0, with the floating point patch)...
>
>
>
>
> > 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.)
>
> ---------
>
> So I ended up compiling my segments separately and then letting the linker
> do all the work to link them and this got rid of the "switch may be too
> larger" error.
>
> Ed
>
> ----- Original Message -----
> From: "Ole Grossklaus" <[EMAIL PROTECTED]>
> Newsgroups: palm-dev-forum
> To: "Palm Developer Forum" <[email protected]>
> Sent: Monday, September 18, 2000 12:29 PM
> Subject: "switch may be too large" Assembler error - What is that ??
>
>
> > Hi,
> >
> > I have a strange error message that reads
> > Error: Signed.word overflow switch may be too large; 36598 at 0x7c
> >
> > I'm using PRC-Tools 2.0 in a multi segment application that I'm doing.
> >
> > >From previous postings I have understood that this is a jump distance
> > problem of functions beeing more that 32K away from each other.
> >
> > I have tried re-arranging my functions in section but with no success. I
> > have understood that this section-thing is not known by the assembler at
> > that point so I haven't assumed to be successfull.
> >
> > I have tried re-arranging the function prototype definitions- no luck.
> >
> > I have tried re-arranging the functions themselfes - again no luck.
> >
> > Is there anybody out there who can sheed some more light on this problem
> and
> > may give some detailed advises how to solve that ?
> >
> > Thanks a lot in advance
> > Ole
> >
> >
> >
> >
> >
> >
> > --
> > 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 ACCESS Developer Forums, or to unsubscribe, please
see http://www.access-company.com/developers/forums/
