public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: "C Jaiprakash, Noida" <cjaiprakash@hcltech.com>
To: binutils@sources.redhat.com
Cc: cjaiprakash@noida.hcltech.com
Subject: RFC:elf32-m68k.c for coldfire v4e
Date: Thu, 10 Feb 2005 13:27:00 -0000	[thread overview]
Message-ID: <267988DEACEC5A4D86D5FCD780313FBB044A8245@exch-03.noida.hcltech.com> (raw)

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

             reply	other threads:[~2005-02-10  9:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-10 13:27 C Jaiprakash, Noida [this message]
2005-02-10 13:51 ` Alan Modra
2005-02-10 20:08   ` Andreas Schwab
2005-02-10 23:24   ` Peter Barada
2005-02-11  0:40     ` Alan Modra
2005-02-10 17:24 ` Andreas Schwab
2005-02-10 21:31 ` Peter Barada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=267988DEACEC5A4D86D5FCD780313FBB044A8245@exch-03.noida.hcltech.com \
    --to=cjaiprakash@hcltech.com \
    --cc=binutils@sources.redhat.com \
    --cc=cjaiprakash@noida.hcltech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).