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,
=
next prev parent 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).