#74 text_64k linker script has no effects

[david buchmann]

i have an application that built fine until it grow too
large for the code segment to fit into the 32k limit. i
found that adding a -T text_64k should make the text
segment to 64k, which would save me until you implement
automatic generation of multiple code resources.

but i can see no effects.

i call
m68k-palmos-gcc -Wl,-T /usr/m68k-palmos/lib/text_64k -o
app a.o b.o ...

and what i get is still
/usr/m68k-palmos/lib/crt0.o: In function `start':
crt0.c:62: relocation truncated to fit: DISP16
_GccRelocateData
crt0.c:64: relocation truncated to fit: DISP16 __do_bhook
crt0.c:67: relocation truncated to fit: DISP16 __do_ctors
crt0.c:72: relocation truncated to fit: DISP16 __do_dtors
crt0.c:74: relocation truncated to fit: DISP16 __do_ehook

not even the number of functions relocated does change.

if i call m68k-palmos-ld directly, i get about 10 pages of

Favform.cpp:51: undefined reference to `__builtin_new'
Favform.cpp(.text+0x1a2): undefined reference to `__throw'
Favform.cpp(.text+0x1ac): undefined reference to
`__builtin_delete'

and similar.

and again, no difference if i pass -T text_64k or not.

i use the latest released version 2.2 of
m68k-palmos-gcc, downloaded last week from sourceforge.

i would be happy if you could figure out what goes
wrong here...

[Nobody/Anonymous]

Logged In: NO

You should see at least one difference with the -T text_64k
option: without that option, there should be a message about
the coderes section being full.

Although the coderes section can be increased in size to 64k,
calls within the text section are still limited to 32k.
The "relocation truncated to fit: DISP16" indicates that a
jump or call within the coderes segment exceeds the 32k
limit.

The problem is crt0.o is located at the beginning of the
segment and references the symbols __do_... which are
located near the end of the segment.

I don't know if it is required that crt0.o be located at the
beginning of the coderes segment, but if not, by relocating
crt0.o to just below 32k into the segment, you may be able
to work around the problem. It may be valueable to produce
a map using the -Map<filename> option and the -noinhibit-
exec option to see what object lies before the 32k limit by
looking at the filename used for the map.

bubbarati@yahoo.com