prc tools linker problem. Help!

[Jim]

Hi,

I'm using prctools under cygwin to do some embedded stuff on a palm
IIIx. Everything was going well (debugging, calling functions, writing
to registers & flash rom, etc.) until I needed a global variable...

My test program that shows the problem:

unsigned char __stack[0x1000];
char g_MyChar;

int main(void)
{
int id;
char * pMyChar = g_MyChar;
return 0;
}

The linker complains with the following:
relocation truncated to fit: END16 g_MyChar

It compiles & links ok using another m68k toolset. So, it tells me it
has something to do with some PalmOs mods (it's a 16 bit OS). It can't
be that my code area is too far away form my data area (it's only a 100
or so bytes). I'm guessing there's some "qualifier" or something I
need to access the global variable--either in the linker script file or
in my source. Hours of a google search turned up nothing.

I REALLY want to use prctools 'cause gdb works with the palm debugger.
Mighty convenient. And my Win98 won't build a compiler under cygwin.
:(

Anyone know what's going on here?

Thanks much!

Jim

[Lanarcam]

It's me or this one would be better ?
char * pMyChar = &g_MyChar;

[Jim]

Lanarcam,

Oops, a typo (meant char * pMyChar = &g_MyChar;).

Jim

[Terry]

Jim,

If you plan on running this by the Palm OS, you should be using
PilotMain() instead of main(void). The prctools crt0 expects a
PilotMain() instead of main(). If I try to compile this in my environment
I get: "/usr/m68k-palmos/lib/crt0.o(.text+0x64): In function `start':
crt0.c:69: undefined reference to `PilotMain' " warning from the linker.

Terry

[Jim]

Terry,

I'm not using Palm OS. I'm developing my own firmware that bypasses
it. I handled the PilontMain() issue with my own crt.S file (adapted
from the one in prctools). I just have this bizarre global variables
access problem which I'm guessing has to to with some imposed
limitation of the 16b OS and that limitation was integrated into the
gnu linker.

Jim

[larwe]

Jim wrote:
> has something to do with some PalmOs mods (it's a 16 bit OS). It can't
> be that my code area is too far away form my data area (it's only a 100
> or so bytes). I'm guessing there's some "qualifier" or something I

What does your linker script say? In particular, what are the load
addresses of the TEXT and DATA sections? If they're more than 32K
apart, the lea offset[reg] addressing mode of the M68K won't be able to
handle it.

[Jim]

larwe,

Thanks for the suggestion. I already checked where things are in
memory. The map file for the small program I previously posted says
all sections (bss, data, text, stack) fit in a 4K area in ram
(0x00020400 for .text start to 0x00021480 for .bss end which includes
the stack & g_MyChar). Ya know, it's interesting a map file was
produced even though the linker failed. Hmmm.

I'm now wondering if my section addresses are conflicting with
something internal to the linker which is customized for PalmOS. For
.text start I used the same address found in a linker script for linux
on the palm. Perhaps this wasn't a wise choice? Comments?

Thanks,

Jim

[Lanarcam]

This is perhaps irrelevant but your global variable is odd aligned
and at the end of the section. Could you try to add a char before
of after your global variable?

unsigned char __stack[0x1000];
char a;
char g_MyChar;

or

unsigned char __stack[0x1000];
char g_MyChar;

char b;

[Jim]

Lanarcam,

It's not odd aligned. And if the linker really wanted it on an even
boundary (and it appears it does), it would place it there. Also,
__stack is at the end of the segment.

Thanks for your suggestion.

Jim

[ophidian]

You imply that your code compiles cleanly, and the problem is in the
link stage. Nevertheless, have you tried splitting the declaration &
assignment? I.e.

int main(void)
{
int id;
char *pMyChar;

*pMyChar = g_MyChar;
return 0;
}