public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Kai Tietz <Kai.Tietz@onevision.com>
To: "H. J. Lu" <hjl@lucon.org>, binutils@sourceware.org
Subject: PATCH: Little endian target "binary_little"
Date: Fri, 27 Apr 2007 12:40:00 -0000	[thread overview]
Message-ID: <OF9D96FC04.DC7033D8-ONC12572CA.002D51FF-C12572CA.002F92AD@onevision.de> (raw)
In-Reply-To: <20070427033347.GA17560@lucon.org>

[-- Attachment #1: Type: text/plain, Size: 1482 bytes --]

Hello,

I want to introduce an new internal default bfd target "binary_little". 
The reason was, that target "binary" is implicit big-endian, but for 
little endian resource it would be very helpful to have  a little endian 
version of "binary", too. E.g. moving windres tool I/O to use bfd instead 
of FILE I/O this is very usable, because for output the bfd_put_?? and 
bfd_get_?? methods can be used without the need of additionally swapping 
the values.

ChangeLog:

2007-04-27  Kai Tietz   <kai.tietz@onevision.com>

        * bfd/binary.c (binary_little_vec): New.
        * bfd/archures.c: (bfd_arch_get_compatible): Check for
        binary_little target.
        * bfd/format.c: (bfd_check_format_matches): Add
        support of binary_little_vec.
        * bfd/targets.c: Add binary_little_vec to default targets.


Regards,
 i.A. Kai Tietz


------------------------------------------------------------------------------------------
  OneVision Software Entwicklungs GmbH & Co. KG
  Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
  Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
  Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
  Handelsregister: HRA 6744, Amtsgericht Regensburg
  Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
  Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
  Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer: 
Ulrike Döhler, Manuela Kluger


[-- Attachment #2: binary_little.txt --]
[-- Type: text/plain, Size: 4549 bytes --]

Index: bfd/archures.c
===================================================================
RCS file: /cvs/src/src/bfd/archures.c,v
retrieving revision 1.125
diff -b -u -r1.125 archures.c
--- bfd/archures.c	26 Apr 2007 14:46:55 -0000	1.125
+++ bfd/archures.c	27 Apr 2007 08:30:14 -0000
@@ -703,7 +703,8 @@
 	 only be set by explicit request from the user, it is safe
 	 to assume that they know what they are doing.  */
       if (accept_unknowns
-	  || strcmp (bfd_get_target (ubfd), "binary") == 0)
+	  || strcmp (bfd_get_target (ubfd), "binary") == 0
+	  || strcmp (bfd_get_target (ubfd), "binary_little") == 0)
 	return ubfd->arch_info;
       return NULL;
     }
Index: bfd/binary.c
===================================================================
RCS file: /cvs/src/src/bfd/binary.c,v
retrieving revision 1.32
diff -b -u -r1.32 binary.c
--- bfd/binary.c	26 Apr 2007 14:46:55 -0000	1.32
+++ bfd/binary.c	27 Apr 2007 08:30:19 -0000
@@ -374,3 +374,55 @@
 
   NULL
 };
+
+const bfd_target binary_little_vec =
+{
+  "binary_little",		/* name */
+  bfd_target_unknown_flavour,	/* flavour */
+  BFD_ENDIAN_UNKNOWN,		/* byteorder */
+  BFD_ENDIAN_UNKNOWN,		/* header_byteorder */
+  EXEC_P,			/* object_flags */
+  (SEC_ALLOC | SEC_LOAD | SEC_READONLY | SEC_CODE | SEC_DATA
+   | SEC_ROM | SEC_HAS_CONTENTS), /* section_flags */
+  0,				/* symbol_leading_char */
+  ' ',				/* ar_pad_char */
+  16,				/* ar_max_namelen */
+  bfd_getl64, bfd_getl_signed_64, bfd_putl64,
+  bfd_getl32, bfd_getl_signed_32, bfd_putl32,
+  bfd_getl16, bfd_getl_signed_16, bfd_putl16,	/* data */
+  bfd_getl64, bfd_getl_signed_64, bfd_putl64,
+  bfd_getl32, bfd_getl_signed_32, bfd_putl32,
+  bfd_getl16, bfd_getl_signed_16, bfd_putl16,	/* hdrs */
+  {				/* bfd_check_format */
+    _bfd_dummy_target,
+    binary_object_p,
+    _bfd_dummy_target,
+    _bfd_dummy_target,
+  },
+  {				/* bfd_set_format */
+    bfd_false,
+    binary_mkobject,
+    bfd_false,
+    bfd_false,
+  },
+  {				/* bfd_write_contents */
+    bfd_false,
+    bfd_true,
+    bfd_false,
+    bfd_false,
+  },
+
+  BFD_JUMP_TABLE_GENERIC (binary),
+  BFD_JUMP_TABLE_COPY (_bfd_generic),
+  BFD_JUMP_TABLE_CORE (_bfd_nocore),
+  BFD_JUMP_TABLE_ARCHIVE (_bfd_noarchive),
+  BFD_JUMP_TABLE_SYMBOLS (binary),
+  BFD_JUMP_TABLE_RELOCS (_bfd_norelocs),
+  BFD_JUMP_TABLE_WRITE (binary),
+  BFD_JUMP_TABLE_LINK (binary),
+  BFD_JUMP_TABLE_DYNAMIC (_bfd_nodynamic),
+
+  NULL,
+
+  NULL
+};
Index: bfd/format.c
===================================================================
RCS file: /cvs/src/src/bfd/format.c,v
retrieving revision 1.24
diff -b -u -r1.24 format.c
--- bfd/format.c	26 Apr 2007 14:46:58 -0000	1.24
+++ bfd/format.c	27 Apr 2007 08:30:39 -0000
@@ -117,6 +117,7 @@
 bfd_check_format_matches (bfd *abfd, bfd_format format, char ***matching)
 {
   extern const bfd_target binary_vec;
+  extern const bfd_target binary_little_vec;
   const bfd_target * const *target;
   const bfd_target **matching_vector = NULL;
   const bfd_target *save_targ, *right_targ, *ar_right_targ;
@@ -198,7 +199,9 @@
 	 actual pe-i386 archive.  Since there may be other problems of
 	 this sort, I changed this test to check only for the binary
 	 target.  */
-      if (format == bfd_archive && save_targ == &binary_vec)
+      if (format == bfd_archive
+      	  && (save_targ == &binary_vec
+      	      || save_targ == &binary_little_vec))
 	{
 	  abfd->xvec = save_targ;
 	  abfd->format = bfd_unknown;
@@ -218,7 +221,7 @@
       bfd_error_type err;
 
       /* Don't check the default target twice.  */
-      if (*target == &binary_vec
+      if (*target == &binary_vec || *target == &binary_little_vec
 	  || (!abfd->target_defaulted && *target == save_targ))
 	continue;
 
Index: bfd/targets.c
===================================================================
RCS file: /cvs/src/src/bfd/targets.c,v
retrieving revision 1.161
diff -b -u -r1.161 targets.c
--- bfd/targets.c	26 Apr 2007 14:46:58 -0000	1.161
+++ bfd/targets.c	27 Apr 2007 08:30:41 -0000
@@ -810,6 +810,7 @@
 extern const bfd_target symbolsrec_vec;
 extern const bfd_target tekhex_vec;
 extern const bfd_target binary_vec;
+extern const bfd_target binary_little_vec;
 extern const bfd_target ihex_vec;
 
 /* All of the xvecs for core files.  */
@@ -1190,6 +1191,7 @@
 	&tekhex_vec,
 /* Likewise for binary output.  */
 	&binary_vec,
+	&binary_little_vec,
 /* Likewise for ihex.  */
 	&ihex_vec,
 
=

  reply	other threads:[~2007-04-27  8:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-26 14:43 Why aren't we consistent on displacement in x86 disassembler? H. J. Lu
2007-04-26 14:54 ` H. J. Lu
2007-04-26 15:54   ` Jan Beulich
2007-04-26 15:59     ` H. J. Lu
2007-04-26 16:05       ` Jan Beulich
2007-04-26 16:23         ` H. J. Lu
2007-04-26 16:31     ` Alan Modra
2007-04-26 17:19       ` H. J. Lu
2007-04-27  8:40         ` PATCH: PR binutils/4430: We aren't consistent on displacement in x86 disassembler H. J. Lu
2007-04-27 12:40           ` Kai Tietz [this message]
2007-04-27 13:54             ` PATCH: Little endian target "binary_little" Alan Modra
2007-04-27 14:54               ` Kai Tietz
2007-04-27 16:26                 ` Alan Modra
2007-04-27 13:39           ` PATCH: PR binutils/4430: We aren't consistent on displacement in x86 disassembler Paul Brook

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=OF9D96FC04.DC7033D8-ONC12572CA.002D51FF-C12572CA.002F92AD@onevision.de \
    --to=kai.tietz@onevision.com \
    --cc=binutils@sourceware.org \
    --cc=hjl@lucon.org \
    /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).