From: Alan Modra <amodra@gmail.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: Binutils Development <binutils@sourceware.org>,
GDB Patches <gdb-patches@sourceware.org>,
Pedro Alves <palves@redhat.com>,
Jan Kratochvil <jan.kratochvil@redhat.com>,
"H. J. Lu" <hongjiu.lu@intel.com>
Subject: Re: [PATCH 1/3] Implement new Linux target vectors on BFD
Date: Wed, 30 Jan 2013 09:16:00 -0000 [thread overview]
Message-ID: <20130130091631.GM3244@bubble.grove.modra.org> (raw)
In-Reply-To: <m3d2wnyxfl.fsf@redhat.com>
On Wed, Jan 30, 2013 at 04:52:46AM -0200, Sergio Durigan Junior wrote:
> 1) Add new target vectors on the BFD configury system in order to handle
> Linux targets, which will then make it possible to use certain functions
> only on such targets, and
Duplicating targets isn't a really good idea.
If on my x86_64 linux box I want to build a native binutils that also
supports powerpc64, I can configure binutils with
--enable-targets=powerpc64-linux, or get all targets with
--enable-targets=all. The problem with adding bfd targets as you've
done is that now you have two bfd targets that give equally good
matches for powerpc64 objects. So instead of one "best" match we now
have two. elf64-big will also match, and by a quirk of the way
bfd_check_format_matches operates (giving priority to targets
appearing in config.bfd targ_selvec), this match will be chosen over
the better elf64-powerpc-* matches. That means a worse user
experience for say, "objdump -d". A file that used to happily
disassemble now gives you
some_file: file format elf64-big
binutils/objdump: can't disassemble for architecture UNKNOWN!
You may have noticed that we've already made a mess of targets for
ARM, i386, x86_64 and powerpc. I'd rather not see the same happen for
powerpc64 without a really good reason.
--
Alan Modra
Australia Development Lab, IBM
next prev parent reply other threads:[~2013-01-30 9:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-30 6:53 Sergio Durigan Junior
2013-01-30 9:16 ` Alan Modra [this message]
2013-01-30 16:43 ` Sergio Durigan Junior
2013-01-31 17:19 ` Pedro Alves
2013-01-31 23:04 ` [PATCH 1/2] New entry points for writing Linux NT_PRPSINFO notes Pedro Alves
2013-02-01 6:37 ` Alan Modra
2013-02-03 2:51 ` Sergio Durigan Junior
2013-02-04 18:31 ` Sergio Durigan Junior
2013-01-31 23:05 ` [PATCH 2/2] Put more info in NT_PRPSINFO Linux notes Pedro Alves
2013-02-03 21:05 ` Sergio Durigan Junior
2013-02-04 16:36 ` Pedro Alves
2013-02-04 18:41 ` Sergio Durigan Junior
2013-01-30 16:44 ` [PATCH 1/3] Implement new Linux target vectors on BFD H.J. Lu
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=20130130091631.GM3244@bubble.grove.modra.org \
--to=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=hongjiu.lu@intel.com \
--cc=jan.kratochvil@redhat.com \
--cc=palves@redhat.com \
--cc=sergiodj@redhat.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