Re: Bogus position independent code(PIC) emitted for ColdFire v4e

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

>Unfortunately ColdFire v4e can't handle the addressing mode of the
>instruction at 0x80000108 since that requires a 32 bit offset.
>I need to modify the compiler to generate PIC code for that
>instruction to look like:
>
>	 move.l  #0x18,%r
>	 move.l  (%a5,%r),%a0
>
>where '%r' is a temporary register.  I've started looking at
>legitimize_pic_address, (gcc/config/m68k/m68k.c) and my eyes starte to
>glaze over.  The leading comment indicates that the "compiler loads
>the address of foo into a register".  Is this legitimize_pic_address,
>or somewhere else that does this (say movsi)?

I started looking at brute-forcing a change in legitimize_pic_address
to force the symbol into the temp register and then adding %a5 on top
of it. This brought me to how the operand is printed.  for m68k if
flag_pic is on, then any reference that includes %a5 has @GOT appended
automatically.  Unfortunatley if I split the symbol off and place it
in a register, I need a way to get '@GOT' added to it in print_operand
I've looked at how i386 does it, and I'm not too keen on introducing
UNSPEC wrappers around the RTX for the symbol(and how much other m68k
specific RTL manitipluation code needs to know about the UNSPEC).  I
looked at the cris port, and saw that it uses ENCODE_SECTION_INFO and
some helper functions to mark the symbol as being in GOT. 

Should I use ENCODE_SECTION_INFO for m68k/ColdFire, or bite the bullet
and go the UNSPEC route?

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