new architecture teething pains

[Peter Barada <pbarada at mail dot wm dot sps dot mot dot com>]

This is probably the wrong place to ask, but its the best place I know
of to ask....

I'm trying to build a complete toolchain for the latest coldfire core that
Motorola produces.  See the following URL for more details on the core:
http://e-www.motorola.com/news_center/press_releases/PR001011C.html 

I've hacked up binutiles-2.11/gcc-2.95.3 to understand '-mcfv4e'
which means to accept/produce instructions of the v4e architecture,
and now I'm working on glibc.  Yes, glibc.  I'm planning on building a
Linux machine around this architecture. 

In glibc-2.2.2, I've cloned all of the sysdep/m68k into
sysdep/coldfire, renaming m68k -> coldfire along the way and added
coldfire to the appropriate places in configure and
scripts/config.sub, ripped out all of sysdep/coldfire/fpu(I'll deal
with the FPU later), fix sysdeps/coldfire/bits/byteswap.h(since
coldfire doesn't have a rotate instruction), and pretty much got glib
to push a massive amount of code through the compiler. 

Where I'm currently stuck is in sysdeps/coldfire/dl-machine.h with the
macro RTLD_START().

1) I wonder what parameters(and where they are) the function
_dl_start_user is called with.

2) Since the ColdFire doesn't support Memory Indirect Postindexed
     Mode, I'll assume the following instruction(found three past
     _dl_start_user): 
     move.l %sp, ([__libc_stack_end@GOT.w, %a5])
   is equivalent to:
     move.l __libc_stack_end@GOT.w(%a5), %a0
     move.l (%a0),%a0
     move.l %sp, (%a0)
   assuming that %a0 can be clobbered, right?

3) Ditto for the 4th instruction in _dl_start_user:
     move.l ([_dl_skip_args@GOT.w, %a5]), %d0
   becomes:
     move.l _dl_skip_args@GOT.w(%a5), %a0
     move.l (%a0),%d0
   assuming that %a0 can be clobbered, right?

4) Ditto for the 12th instruction in _dl_start_user:
     move.l ([_dl_loaded@GOT.w, %a5]), -(%sp)
   becomes:
     move.l _dl_loaded@GOT.w(%a5), %a0
     move.l (%a0),-(%sp)
   assuming that %a0 can be clobbered, right?

Following these changes it build along until it tries to link ld.so:

m68k-linux-gcc   -nostdlib -nostartfiles -r -o /home/pbarada/work/cvs-wavemark/cross-linux-tools/obj/m68k-linux/build-glibc/elf/librtld.os '-Wl,-(' /home/pbarada/work/cvs-wavemark/cross-linux-tools/obj/m68k-linux/build-glibc/elf/dl-allobjs.os /home/pbarada/work/cvs-wavemark/cross-linux-tools/obj/m68k-linux/build-glibc/libc_pic.a -lgcc '-Wl,-)'
m68k-linux-gcc   -nostdlib -nostartfiles -shared -o /home/pbarada/work/cvs-wavemark/cross-linux-tools/obj/m68k-linux/build-glibc/elf/ld.so  \
	  /home/pbarada/work/cvs-wavemark/cross-linux-tools/obj/m68k-linux/build-glibc/elf/librtld.os		\
	  -Wl,--version-script=/home/pbarada/work/cvs-wavemark/cross-linux-tools/obj/m68k-linux/build-glibc/ld.map -Wl,-soname=ld.so.1
/home/pbarada/work/cvs-wavemark/cross-linux-tools/obj/m68k-linux/build-glibc/elf/librtld.os: In function `_dl_start_user':
/home/pbarada/work/cvs-wavemark/cross-linux-tools/obj/m68k-linux/build-glibc/elf/librtld.os: In function `_dl_start':
/home/pbarada/work/cvs-wavemark/cross-linux-tools/glibc-2.2.2/elf/rtld.c:148: relocation truncated to fit: R_68K_GOT16 _GLOBAL_OFFSET_TABLE_
...

Looking at the assembler of rtld.c around line 148 shows the prologue
of the _dl_start function:

	.type	 _dl_start,@function
_dl_start:
	link.w %a6,#-456
	lea (-40,%sp),%sp
	movm.l #0x3cfc,(%sp)
	lea (%pc, _GLOBAL_OFFSET_TABLE_@GOTPC), %a5
	clr.l %d1
	lea (-390,%a6),%a2

And I'm guessing that the linker is none to happy about relocating
_GLOBAL_OFFSET_TABLE_@GOTPC in only 15 sign extended bits.  So if I
can get the compiler to crank out:

_dl_start:
	link.w %a6,#-456
	lea (-40,%sp),%sp
	movm.l #0x3cfc,(%sp)
	move.l #_GLOBAL_OFFSET_TABLE_@GOTPC, %d0
	lea (%pc, %d0), %a5

Then life should be fine, right?

Another issue I ran across is trying to use the byte offset
conditionals.  They're obviously not long enough for some of hte
branches, but if all the branches are word offset, then the code size
baloons dramatically.  Is there any way in the linker to shrink a word
branch into a byte branch if the offset is in the range of +/- 127?
Are there other architectures that do this?  I know I can write a post
pass for the assembler(which I've done before), but I though I'd ask
before bounding off on that path.

Any suggestions/advice will be most appreciated.
Thanks in advance!

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com