RFC:elf32-m68k.c for coldfire v4e

RFC:elf32-m68k.c for coldfire v4e

[C Jaiprakash, Noida]

Hi,
  I think I have struck in an unusual problem. I have to modify PLT entries
in elf32-m68k.c file so that they are valid for coldfire v4e. (due to
constraints in addr mode). I could successfully modify and test the changes.


Though these changes should be valid for m68k as well but the size of PLT is
increased a bit. What I want to know is will this be acceptable? If not then

How can I decide which PLT is to be used among m68k, cpu32 or cfv4e? I may
create a new target may be coldfire-linux but there will be a code
duplication of elf32-m68k.c. I hope I am clear in expressing. I am also
attaching the patch with this mail ( just for review )

@@ -192,6 +192,7 @@
 /* The size in bytes of an entry in the procedure linkage table.  */

 #define PLT_ENTRY_SIZE 20
+#define CFV4E_PLT_ENTRY_SIZE 24 /* Changes for cfv4e target */

 /* The first entry in a procedure linkage table looks like this.  See
    the SVR4 ABI m68k supplement to see how this works.  */
@@ -217,6 +218,34 @@
   0, 0, 0, 0             /* replaced with offset to start of .plt.  */
 };

+/*  PLT for cfv4e */
+static const bfd_byte elf_cfv4e_plt0_entry[CFV4E_PLT_ENTRY_SIZE] =
+{
+  0x20, 0x3c,
+  0, 0, 0, 0,             /* replaced with offset to .got + 4.  */
+  0x2f, 0x3b, 0x08, 0xfa, /* move.l (%pc,addr),-(%sp) */
+  0x20, 0x3c,
+  0, 0, 0, 0,             /* replaced with offset to .got + 8.  */
+  0x20, 0x7b, 0x08, 0x00, /* move.l (%pc,%d0:l), %a0 */
+  0x4e, 0xd0,             /* jmp (%a0) */
+  0x4e, 0x71
+};
+
+/* Subsequent entries in a procedure linkage table look like this.  */
+
+static const bfd_byte elf_cfv4e_plt_entry[CFV4E_PLT_ENTRY_SIZE] =
+{
+  0x20, 0x3c,
+  0, 0, 0, 0,             /* replaced with offset to symbol's .got entry.
*/
+  0x20, 0x7b, 0x08, 0x00, /* move.l (%pc,%d0:l), %a0 */
+  0x4e, 0xd0,             /* jmp (%a0) */
+  0x2f, 0x3c,             /* move.l #offset,-(%sp) */
+  0, 0, 0, 0,             /* replaced with offset into relocation table.
*/
+  0x60, 0xff,             /* bra.l .plt */
+  0, 0, 0, 0              /* replaced with offset to start of .plt.  */
+};
+
+
 #define CPU32_FLAG(abfd)  (elf_elfheader (abfd)->e_flags & EF_CPU32)

 #define PLT_CPU32_ENTRY_SIZE 24
@@ -1815,23 +1844,38 @@
           plt_off2 = 12;
           plt_off3 = 18;
         }
-      else
+      else /* For cfv4e:  */
+        {
+          plt_off1 = 2;
+          plt_off2 = 14;
+          plt_off3 = 20;
+
+        }
+      /*else  for m68k
         {
-          /* Fill in the entry in the procedure linkage table.  */
+           Fill in the entry in the procedure linkage table.
           memcpy (splt->contents + h->plt.offset, elf_m68k_plt_entry,
                  PLT_ENTRY_SIZE);
           plt_off1 = 4;
           plt_off2 = 10;
           plt_off3 = 16;
-        }
+        } */

       /* The offset is relative to the first extension word.  */
-      bfd_put_32 (output_bfd,
+      /* bfd_put_32 (output_bfd,
                  (sgot->output_section->vma
                   + sgot->output_offset
                   + got_offset
                   - (splt->output_section->vma
                      + h->plt.offset + 2)),
+                 splt->contents + h->plt.offset + plt_off1); */
+      /* else { : For cfv4e */
+      bfd_put_32 (output_bfd,
+                 (sgot->output_section->vma
+                  + sgot->output_offset
+                  + got_offset
+                  - (splt->output_section->vma
+                     + h->plt.offset + 2) - 6),
                  splt->contents + h->plt.offset + plt_off1);

       bfd_put_32 (output_bfd, plt_index * sizeof (Elf32_External_Rela),
@@ -1840,11 +1884,18 @@
                  splt->contents + h->plt.offset + plt_off3);

       /* Fill in the entry in the global offset table.  */
-      bfd_put_32 (output_bfd,
+      /*bfd_put_32 (output_bfd,
                  (splt->output_section->vma
                   + splt->output_offset
                   + h->plt.offset
                   + 8),
+                 sgot->contents + got_offset); */
+      /* else { :  For cfv4e */
+      bfd_put_32 (output_bfd,
+                 (splt->output_section->vma
+                  + splt->output_offset
+                  + h->plt.offset
+                  + 12),
                  sgot->contents + got_offset);

       /* Fill in the entry in the .rela.plt section.  */
@@ -2033,6 +2084,7 @@
           if (!CPU32_FLAG (output_bfd))
             {
              memcpy (splt->contents, elf_m68k_plt0_entry, PLT_ENTRY_SIZE);
+             /*
              bfd_put_32 (output_bfd,
                          (sgot->output_section->vma
                           + sgot->output_offset + 4
@@ -2043,6 +2095,19 @@
                           + sgot->output_offset + 8
                           - (splt->output_section->vma + 10)),
                          splt->contents + 12);
+             */
+             /* else : cfv4e  */
+              bfd_put_32 (output_bfd,
+                          (sgot->output_section->vma
+                           + sgot->output_offset + 4
+                           - (splt->output_section->vma + 2)),
+                          splt->contents + 2);
+              bfd_put_32 (output_bfd,
+                          (sgot->output_section->vma
+                           + sgot->output_offset + 8
+                           - (splt->output_section->vma + 10) - 8 ),
+                          splt->contents + 12);
+
               elf_section_data (splt->output_section)->this_hdr.sh_entsize
                = PLT_ENTRY_SIZE;
             }



Thanks and best regards, 
C Jaiprakash 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
Contributing to the World by creating indispensable value ! 

System Software CoE @ HCLT-Noida 
http://www.hcltechnologies.com 
Ph. : +91-120-2510701/702 Ext : 3170 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

Re: RFC:elf32-m68k.c for coldfire v4e

[Alan Modra]

On Thu, Feb 10, 2005 at 03:26:09PM +0530, C Jaiprakash, Noida wrote:
> Though these changes should be valid for m68k as well but the size of PLT is
> increased a bit. What I want to know is will this be acceptable?

No.  ld.so modifies the PLT, so the layout cannot change.

> If not then
> How can I decide which PLT is to be used among m68k, cpu32 or cfv4e? I may
> create a new target may be coldfire-linux but there will be a code
> duplication of elf32-m68k.c.

Yes, you should use a new target, but there should be no need for code
duplication.  The way you do this is by including elf32-target.h again
in elf32-m68k.c, with some changed defines.  A good example to look at
is the Symbian support in elf32-arm.c, which happens to use a
different PLT layout to other ARM targets.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: RFC:elf32-m68k.c for coldfire v4e

[Andreas Schwab]

"C Jaiprakash, Noida" <cjaiprakash@hcltech.com> writes:

> How can I decide which PLT is to be used among m68k, cpu32 or cfv4e?

What's wrong with a new header flag like EF_CFV4E?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: RFC:elf32-m68k.c for coldfire v4e

[Andreas Schwab]

Alan Modra <amodra@bigpond.net.au> writes:

> ld.so modifies the PLT

m68k has a read-only PLT.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: RFC:elf32-m68k.c for coldfire v4e

[Peter Barada]

>  I think I have struck in an unusual problem. I have to modify PLT entries
>in elf32-m68k.c file so that they are valid for coldfire v4e. (due to
>constraints in addr mode). I could successfully modify and test the changes.
>
>Though these changes should be valid for m68k as well but the size of PLT is
>increased a bit. What I want to know is will this be acceptable? If not then
>
>How can I decide which PLT is to be used among m68k, cpu32 or cfv4e? I may
>create a new target may be coldfire-linux but there will be a code
>duplication of elf32-m68k.c. I hope I am clear in expressing. I am also
>attaching the patch with this mail ( just for review )

You should look into how the code for the CPU32 does it since the
CPU32 has different sized PLT entries as well:

#define CPU32_FLAG(abfd)  (elf_elfheader (abfd)->e_flags & EF_CPU32)

The EF_CPU32 flag is set in the elf header in gas/config/tc-m68k.c,
m68k_elf_final_processing(), you should do the same for an added 'EF_MCF'
flag, and use that to decide to use the mcf PLT entry.  Here's the
extract where you'd need to modify the code to decide which to use:

in elf_m68k_adjust_dynamic_symbol:

...

      /* If this is the first .plt entry, make room for the special
	 first entry.  */
      if (s->_raw_size == 0)
	{
	  if (CPU32_FLAG (dynobj))
	    s->_raw_size += PLT_CPU32_ENTRY_SIZE;
	  else
	    s->_raw_size += PLT_ENTRY_SIZE;
	}

...

      /* Make room for this entry.  */
      if (CPU32_FLAG (dynobj))
        s->_raw_size += PLT_CPU32_ENTRY_SIZE;
      else
        s->_raw_size += PLT_ENTRY_SIZE;


Another thing I noticed is that you should comment the plt0 for v4e better
so that you don't need a programmers manual to find that 0x203c is
'move.l #,%d0' and 0x4e71 is 'nop'.  Here's the PLT entries that I
came up with for ColdFire:

#define MCF_FLAG(abfd)    (elf_elfheader (abfd)->e_flags & EF_MCF)

#define PLT_MCF_ENTRY_SIZE 24
/* Procedure linkage table entries for ColdFire */
static const bfd_byte elf_mcf_plt0_entry[PLT_MCF_ENTRY_SIZE] =
{
  0x43, 0xf9,              /* lea addr, %a1 */
  0, 0, 0, 0,              /* replaced with offset to .got + 4 */
  0x2f, 0x3b, 0x98, 0xfa,  /* movel %pc@(-6,%a1),-(%sp) */
  0x43, 0xf9,              /* lea addr, %a1 */
  0, 0, 0, 0,              /* replaced with offset to .got + 8 */
  0x22, 0x7b, 0x98, 0xfa,  /* movel %pc@(-6,%a1),%a1 */
  0x4e, 0xd1,              /* jmp %a1@ */
  0x4e, 0x71,              /* nop */
};

static const bfd_byte elf_mcf_plt_entry[PLT_MCF_ENTRY_SIZE] =
{
  0x43, 0xf9,              /* lea addr, %a1 */
  0, 0, 0, 0,              /* replaced with offset to symbol's .got entry.  */
  0x22, 0x7b, 0x98, 0xfa,  /* movel %pc@(-6,%a1),%a1 */
  0x4e, 0x4d1,             /* jmp %a1@ */
  0x2f, 0x3c,              /* move.l #offset,-(%sp) */
  0, 0, 0, 0,              /* replaced with offset into relocation table.  */
  0x60, 0xff,              /* bra.l .plt */
  0, 0, 0, 0,              /* replaced with offset to start of .plt.  */
};


And the code in elf_m68k_adjust_dynamic_symbol:

...

      /* If this is the first .plt entry, make room for the special
	 first entry.  */
      if (s->_raw_size == 0)
	{
	  if (CPU32_FLAG (dynobj))
	    s->_raw_size += PLT_CPU32_ENTRY_SIZE;
	  else if (MCF_FLAG (dynobj))
	    s->_raw_size += PLT_MCF_ENTRY_SIZE;
          else
	    s->_raw_size += PLT_ENTRY_SIZE;
	}

...

      /* Make room for this entry.  */
      if (CPU32_FLAG (dynobj))
        s->_raw_size += PLT_CPU32_ENTRY_SIZE;
      else if (MCF_FLAG (dynobj))
        s->_raw_size += PLT_MCF_ENTRY_SIZE;
      else
        s->_raw_size += PLT_ENTRY_SIZE;


Drop me a line if you have any further questions...

-- 
Peter Barada
peter@the-baradas.com

Re: RFC:elf32-m68k.c for coldfire v4e

[Peter Barada]

>> Though these changes should be valid for m68k as well but the size of PLT is
>> increased a bit. What I want to know is will this be acceptable?
>
>No.  ld.so modifies the PLT, so the layout cannot change.

Then the CPU32 PLT code shouldn't work since its the CPU32 PLT entries
are larger than the m68k ones....

-- 
Peter Barada
peter@the-baradas.com

Re: RFC:elf32-m68k.c for coldfire v4e

[Alan Modra]

On Thu, Feb 10, 2005 at 12:25:39PM -0500, Peter Barada wrote:
> 
> >> Though these changes should be valid for m68k as well but the size of PLT is
> >> increased a bit. What I want to know is will this be acceptable?
> >
> >No.  ld.so modifies the PLT, so the layout cannot change.
> 
> Then the CPU32 PLT code shouldn't work since its the CPU32 PLT entries
> are larger than the m68k ones....

Duh.  I'm just not thinking straight.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre