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

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

[Peter Barada]

>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)

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

[Richard Henderson]

On Fri, Dec 06, 2002 at 12:46:19PM -0500, Peter Barada wrote:
> Should I use ENCODE_SECTION_INFO for m68k/ColdFire, or bite the bullet
> and go the UNSPEC route?

I think you're better off going the UNSPEC route.


r~

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

[Peter Barada]

>> Should I use ENCODE_SECTION_INFO for m68k/ColdFire, or bite the bullet
>> and go the UNSPEC route?
>
>I think you're better off going the UNSPEC route.

Are there any gotchas that I should be aware of(i.e. using UNSPEC will
definitely *break* something in the 68k port)?

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

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

[Peter Barada]

>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...

I've modified the symbol/label clause of legitimize_pic_address to
look like:

  /* First handle a simple SYMBOL_REF or LABEL_REF */
  if (GET_CODE (orig) == SYMBOL_REF || GET_CODE (orig) == LABEL_REF)
    {
      if (reg == 0)
	abort ();

      if (TARGET_COLDFIRE)
        {
          /* Get the symbol into the register */
          emit_insn (gen_rtx_SET (Pmode, reg, orig));
          /* Now add the pic_offset_table_rtx to it and load indirect */
          pic_ref = gen_rtx_MEM (Pmode,
                                 gen_rtx_PLUS (Pmode,
                                               pic_offset_table_rtx, reg));
        }
      else
        {
          pic_ref = gen_rtx_MEM (Pmode,
                                 gen_rtx_PLUS (Pmode,
                                               pic_offset_table_rtx, orig));
        }
      current_function_uses_pic_offset_table = 1;
      RTX_UNCHANGING_P (pic_ref) = 1;
      emit_move_insn (reg, pic_ref);
      return reg;
    }

Which generates the two pieces of rtl for hte ColdFire case:

;; Start of basic block 0, registers live: 13 [%a5] 14 [%a6] 15 [%sp]
(note 23 5 8 [bb 0] NOTE_INSN_BASIC_BLOCK)

(insn 8 23 10 (set:SI (reg/f:SI 30)
        (symbol_ref/i:SI ("__gmon_start__"))) -1 (nil)
    (expr_list:REG_EQUAL (symbol_ref/i:SI ("__gmon_start__"))
        (nil)))

(insn 10 8 14 (set (reg/f:SI 30)
        (mem/u:SI (plus:SI (reg:SI 13 %a5)
                (reg/f:SI 30)) [0 S4 A8])) 30 {*m68k.md:993} (insn_list 8 (nil))
    (nil))

(insn 14 10 15 (set (cc0)
        (reg/f:SI 30)) 3 {*m68k.md:353} (insn_list 10 (nil))
    (nil))


But unfortunately the compine pass puts it back together again:

;; Start of basic block 0, registers live: 13 [%a5] 14 [%a6] 15 [%sp]
(note 23 5 8 [bb 0] NOTE_INSN_BASIC_BLOCK)

(note 8 23 10 NOTE_INSN_DELETED)

(insn 10 8 14 (set (reg/f:SI 30)
        (mem/u:SI (plus:SI (reg:SI 13 %a5)
                (symbol_ref/i:SI ("__gmon_start__"))) [0 S4 A8])) 30 {*m68k.md:993} (nil)
    (nil))

(insn 14 10 15 (set (cc0)
        (reg/f:SI 30)) 3 {*m68k.md:353} (insn_list 10 (nil))
    (nil))



This is valid for 68020 since an SImode can be part of the offset, but
its illegal for ColdFire. In INDIRECTABLE_1_ADDRESS_P I find:

   || (GET_CODE (X) == PLUS && XEXP (X, 0) == pic_offset_table_rtx 	\
       && flag_pic && GET_CODE (XEXP (X, 1)) == SYMBOL_REF)		\
   || (GET_CODE (X) == PLUS && XEXP (X, 0) == pic_offset_table_rtx 	\
       && flag_pic && GET_CODE (XEXP (X, 1)) == LABEL_REF))

1) Should that have been:

   || (GET_CODE (X) == PLUS && XEXP (X, 0) == pic_offset_table_rtx 	\
       && flag_pic && GET_CODE (XEXP (X, 1)) == SYMBOL_REF)		\
   || (GET_CODE (X) == PLUS && XEXP (X, 1) == pic_offset_table_rtx 	\
       && flag_pic && GET_CODE (XEXP (X, 0)) == LABEL_REF))

2) Should this be changed to:

   || (!TARGET_COLDFIRE &&						\
      (GET_CODE (X) == PLUS && XEXP (X, 0) == pic_offset_table_rtx 	\
       && flag_pic && GET_CODE (XEXP (X, 1)) == SYMBOL_REF)		\
   || (GET_CODE (X) == PLUS && XEXP (X, 0) == pic_offset_table_rtx 	\
       && flag_pic && GET_CODE (XEXP (X, 1)) == LABEL_REF))

To force an addition of a symbol ref and the PIC register to be
rejected, or am I overlooking something...

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

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

[Peter Barada]

My my attempt to understand how INDIRECTABLE_1_ADRESS_P is affected
for PIC, I made the following change to m68k.h:

#if 1
#define INDIRECTABLE_1_ADDRESS_P(X) m68k_indirectable_1_address_p(X)
#else
#define INDIRECTABLE_1_ADDRESS_P(X)  \
  ((CONSTANT_ADDRESS_P (X) && (!flag_pic || LEGITIMATE_PIC_OPERAND_P (X))) \
   || LEGITIMATE_BASE_REG_P (X)						\
   || ((GET_CODE (X) == PRE_DEC || GET_CODE (X) == POST_INC)		\
       && LEGITIMATE_BASE_REG_P (XEXP (X, 0)))				\
   || (GET_CODE (X) == PLUS						\
       && LEGITIMATE_BASE_REG_P (XEXP (X, 0))				\
       && GET_CODE (XEXP (X, 1)) == CONST_INT				\
       && (TARGET_68020							\
	   || ((unsigned) INTVAL (XEXP (X, 1)) + 0x8000) < 0x10000))	\
   || (GET_CODE (X) == PLUS && XEXP (X, 0) == pic_offset_table_rtx 	\
       && flag_pic && GET_CODE (XEXP (X, 1)) == SYMBOL_REF)		\
   || (GET_CODE (X) == PLUS && XEXP (X, 0) == pic_offset_table_rtx 	\
       && flag_pic && GET_CODE (XEXP (X, 1)) == LABEL_REF))
#endif

And added the following function to m68k.c:

int m68k_indirectable_1_address_p(X)
     rtx X;
{
  if ((CONSTANT_ADDRESS_P (X) && (!flag_pic || LEGITIMATE_PIC_OPERAND_P (X)))
      || (LEGITIMATE_BASE_REG_P (X))
      || ((GET_CODE (X) == PRE_DEC || GET_CODE (X) == POST_INC)
          && LEGITIMATE_BASE_REG_P (XEXP (X, 0)))
      || (GET_CODE (X) == PLUS
       && LEGITIMATE_BASE_REG_P (XEXP (X, 0))
       && GET_CODE (XEXP (X, 1)) == CONST_INT
       && (TARGET_68020
	   || ((unsigned) INTVAL (XEXP (X, 1)) + 0x8000) < 0x10000))
      || (GET_CODE (X) == PLUS && XEXP (X, 0) == pic_offset_table_rtx
          && flag_pic && GET_CODE (XEXP (X, 1)) == SYMBOL_REF)
      || (GET_CODE (X) == PLUS && XEXP (X, 0) == pic_offset_table_rtx
          && flag_pic && GET_CODE (XEXP (X, 1)) == LABEL_REF))
    return !0;
  return 0;
}


As well as the appropriate prototype to m68k-protos.h:

extern int m68k_indirectable_1_address_p PARAMS ((rtx));

And configured with:

/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/configure --with-gcc-version-trigger=/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/version.c --host=i686-pc-linux-gnu --target=m68k-linux --prefix=/home/mylocal/cf-linux --enable-languages=c --with-local-prefix=/home/mylocal/cf-linux/m68k-linux --without-headers --with-newlib --disable-shared --disable-threads --verbose

It blew up while building with:

/home/pbarada/work/cvs-wavemark/cross-linux-tools/obj/cf-linux/m68k-linux/gcc-bootstrap/gcc/xgcc -B/home/pbarada/work/cvs-wavemark/cross-linux-tools/obj/cf-linux/m68k-linux/gcc-bootstrap/gcc/ -B/home/mylocal/cf-linux/m68k-linux/bin/ -B/home/mylocal/cf-linux/m68k-linux/lib/ -isystem /home/mylocal/cf-linux/m68k-linux/include -O2  -DIN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include  -fPIC -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc -I/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/. -I/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/config -I/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/../include -fexceptions -c /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/unwind-dw2-fde-glibc.c -o libgcc/./unwind-dw2-fde-glibc.o
In file included from /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/unwind-dw2-fde-glibc.c:47:
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/unwind-pe.h: In function `size_of_encoded_value':
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/unwind-pe.h:76: warning: implicit declaration of function `abort'
In file included from /home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/unwind-dw2-fde-glibc.c:298:
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/unwind-dw2-fde.c: In function `get_cie_encoding':
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/unwind-dw2-fde.c:271: warning: implicit declaration of function `strlen'
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/unwind-dw2-fde.c: In function `init_object':
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/unwind-dw2-fde.c:924: unrecognizable insn:
(insn 839 501 503 (set (reg:SI 0 %d0)
        (mem/s:SI (plus:SI (mem:SI (plus:SI (reg/f:SI 14 %a6)
                        (const_int -20 [0xffffffec])) [33 v2 S4 A8])
                (const_int 4 [0x4])) [4 <variable>.count+0 S4 A16])) -1 (nil)
    (nil))
/home/pbarada/work/cvs-wavemark/cross-linux-tools/gcc-3.2/gcc/unwind-dw2-fde.c:924: Internal compiler error in extract_insn, at recog.c:2148
Please submit a full bug report,

I'm *really* confused here.  I can't see how converting a macro into a
function can cause this type of failure.  If I put
INDIRECTABLE_1_ADDRESS_P back as a macro, then everthing
builds. Really weird. 

I'm using:

[pbarada: ~/work/cvs-wavemark/cross-linux-tools/obj/cf-linux/m68k-linux/gcc-bootstrap] > gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113)

To build the cross compiler.  Are there known bugs in RedHat's 2.96?

I'm attempting to build gcc-3.2.1 and will then try this experiment
again.

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

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

[Richard Henderson]

On Fri, Dec 06, 2002 at 02:38:33PM -0500, Peter Barada wrote:
> Are there any gotchas that I should be aware of(i.e. using UNSPEC will
> definitely *break* something in the 68k port)?

Not that I can think of.  If you wrap the UNSPEC in a CONST, then it
should be considered to be a 32-bit constant, and so will be accepted
anywhere a 32-bit constant is.

Which, for the '020 instruction set is ideal.  Carefully constructed
predicates should be used to allow just the right combinations for 
the coldfire.  E.g.

	(const (unspec [(symbol_ref "foo")] UNSPEC_GOT))

should expand to foo@GOT in the assembly.  But during compilation
we look at -fpic vs -fPIC to determine if this is a 16-bit or a
32-bit quantity, and thus whether it's allowed in the immediate field
of an address.


r~

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

[Peter Barada]

>Not that I can think of.  If you wrap the UNSPEC in a CONST, then it
>should be considered to be a 32-bit constant, and so will be accepted
>anywhere a 32-bit constant is.
>
>Which, for the '020 instruction set is ideal.  Carefully constructed
>predicates should be used to allow just the right combinations for 
>the coldfire.  E.g.
>
>	(const (unspec [(symbol_ref "foo")] UNSPEC_GOT))

Thanks for the info.  I'll start loking at implementing this over the
weekend.  Should I be concerned about @PLT stuff at this time or just
hope that its taken care of...


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

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

[Richard Henderson]

On Fri, Dec 06, 2002 at 08:27:25PM -0500, Peter Barada wrote:
> Thanks for the info.  I'll start loking at implementing this over the
> weekend.  Should I be concerned about @PLT stuff at this time or just
> hope that its taken care of...

I'd wait and do that separately.

Keep in mind that you'll want to distinguish between
@GOT and @GOTPC.


r~

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

[Peter Barada]

>> Thanks for the info.  I'll start loking at implementing this over the
>> weekend.  Should I be concerned about @PLT stuff at this time or just
>> hope that its taken care of...
>
>I'd wait and do that separately.
>
>Keep in mind that you'll want to distinguish between
>@GOT and @GOTPC.

I'll keep that in mind.  Should I be concerned about uses of
SYMBOL_REF_FLAG in LEGITIATE_PIC_OPERAND
(gcc/config/m68k/m68k.h:1281)?

-- 
Peter Barada
peter@baradas.org

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

[Richard Henderson]

On Sat, Dec 07, 2002 at 05:31:13PM -0500, Peter Barada wrote:
> Should I be concerned about uses of
> SYMBOL_REF_FLAG in LEGITIATE_PIC_OPERAND
> (gcc/config/m68k/m68k.h:1281)?

Yes.

It looks like all of this should be rewritten...


r~

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

[Richard Henderson]

On Mon, Dec 09, 2002 at 12:25:01PM -0500, Peter Barada wrote:
> Are your referring to just replacing the SYMBOL_REF_FLAG with
> determining the UNSPEC number, or the *whole* definition in general?

m68k pic symbol manipulation in general.


r~

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

[Peter Barada]

>> Should I be concerned about use of
>> SYMBOL_REF_FLAG in LEGITIATE_PIC_OPERAND_P
>> (gcc/config/m68k/m68k.h:1281)?
>
>Yes.
>
>It looks like all of this should be rewritten...

Are your referring to just replacing the SYMBOL_REF_FLAG with
determining the UNSPEC number, or the *whole* definition in general?

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

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

[Hans-Peter Nilsson]

On Fri, 6 Dec 2002, Richard Henderson wrote:

> On Fri, Dec 06, 2002 at 12:46:19PM -0500, Peter Barada wrote:
> > Should I use ENCODE_SECTION_INFO for m68k/ColdFire, or bite the bullet
> > and go the UNSPEC route?
>
> I think you're better off going the UNSPEC route.

Any particular reason?

I chose the ENCODE_SECTION_INFO route for CRIS, because in a
perfect GCC, going that route would supposedly enable GCC to
optimize symbol references (for example, combining foo and
foo+N).  (Context: the UNSPEC route forbids GCC from looking
through the UNSPEC.)

Right, I *also* use (CONST) UNSPEC, for references that should
go through PLT, expanded at call and call_value.  No harm done
since function references are supposedly not combinable.

brgds, H-P

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

[Richard Henderson]

On Thu, Dec 12, 2002 at 01:33:50AM -0500, Hans-Peter Nilsson wrote:
> > I think you're better off going the UNSPEC route.
> 
> Any particular reason?

First, because there's a clear distinction between 

	static int *x = &foo;
and 
	auto int *x = &foo;

in that the first /must/ be a direct relocation vs foo,
and the second oughtn't be in pic mode.

> I chose the ENCODE_SECTION_INFO route for CRIS, because in a
> perfect GCC, going that route would supposedly enable GCC to
> optimize symbol references (for example, combining foo and
> foo+N).

*shrug*  Often one can use (const (plus (unspec) (const_int))).
Depends on whether or not the spec is broken wrt (foo+N)@GOT,
as it is in many AT&T defined psABIs.


r~

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

[Hans-Peter Nilsson]

On Wed, 11 Dec 2002, Richard Henderson wrote:

> On Thu, Dec 12, 2002 at 01:33:50AM -0500, Hans-Peter Nilsson wrote:
> > > I think you're better off going the UNSPEC route.
> >
> > Any particular reason?
>
> First, because there's a clear distinction between
>
> 	static int *x = &foo;
> and
> 	auto int *x = &foo;
>
> in that the first /must/ be a direct relocation vs foo,
> and the second oughtn't be in pic mode.

FWIW, I don't recall there being a problem with that, going the
ENCODE_SECTION_INFO route.

brgds, H-P

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

[Peter Barada]

>Try -fpic instead of -fPIC.  The former generates 16 bit GOT offsets
>which should be supported by the coldfire.  That distinction is made
>in m68k.c:print_operand_address.

Nice suggestion, but I have to support -fPIC since my application
which I want to port from an x86 linux box already has a GOT that is
larger than 64KB. 


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

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

[Andreas Schwab]

Peter Barada <pbarada@mail.wm.sps.mot.com> writes:

|> I'm in the midst of bringin up a Linux kernel for a ColdFire v4e, and
|> I've just fallen into the rathole of dealing with PIC code.
|> 
|> Near the beggining of the init process, 'call_gmon_start' is called,
|> and its code currently looks like:
|> 
|> 800000f8 <call_gmon_start>:
|> 800000f8:	4e56 0000      	linkw %fp,#0
|> 800000fc:	2f0d           	movel %a5,%sp@-
|> 800000fe:	2a7c 0005 c830 	moveal #378928,%a5
|> 80000104:	4bfb d8fa      	lea %pc@(80000100 <call_gmon_start+0x8>,%a5:l),%a5
|> 80000108:	2075 0170 0000 	moveal %a5@(00000018),%a0
|> 8000010e:	0018 
|> 80000110:	4a88           	tstl %a0
|> 
|> Unfortunately ColdFire v4e can't handle the addressing mode of the
|> instruction at 0x80000108 since that requires a 32 bit offset.

Try -fpic instead of -fPIC.  The former generates 16 bit GOT offsets which
should be supported by the coldfire.  That distinction is made in
m68k.c:print_operand_address.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Bogus position independent code(PIC) emitted for ColdFire v4e

[Peter Barada]

I'm in the midst of bringin up a Linux kernel for a ColdFire v4e, and
I've just fallen into the rathole of dealing with PIC code.

Near the beggining of the init process, 'call_gmon_start' is called,
and its code currently looks like:

800000f8 <call_gmon_start>:
800000f8:	4e56 0000      	linkw %fp,#0
800000fc:	2f0d           	movel %a5,%sp@-
800000fe:	2a7c 0005 c830 	moveal #378928,%a5
80000104:	4bfb d8fa      	lea %pc@(80000100 <call_gmon_start+0x8>,%a5:l),%a5
80000108:	2075 0170 0000 	moveal %a5@(00000018),%a0
8000010e:	0018 
80000110:	4a88           	tstl %a0

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)?

Could someone explain the comment "If we need more than one register,
we lose."

Where can I find a reference to how dynamic linking/PIC are supposed
to work(the general overview)?

Any suggestions on the best(or any!) way to emit working PIC for
ColdFire v4e would be most appreciated.

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