This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 19/01/17 23:59, Joel Sherrill wrote:
On 1/19/2017 4:55 PM, Alan Modra wrote:On Thu, Jan 19, 2017 at 09:39:39AM -0600, Joel Sherrill wrote:One of the reasons this was duplicated was to ensure that when someone tinkered with a target they knew XXX-rtems was impacted. With this patch, there is no record of each cpu-rtems being a used target. I know binutils doesn't remove targets often but this makes the individual RTEMS targets invisible. It definitely means we likely don't have to touch these files for new targets but it also means we aren't obvious when deprecation discussions occur. It would be nice to have a binutils maintainer wade in. I can see how this is a nice clean up patch but it loses information. What are the thoughts on this?I would prefer to lose that information. We're talking about bfd/ here, and given that there is no difference between bfd support for <target>-elf and <target>-rtems, it doesn't make much sense to single out rtems targets in config.bfd. The only concern would be if a future change removed support for <target>-elf but you wanted to keep <target>-rtems. However, I can't see us deprecating an ELF target unless all support for <target> is no longer wanted.That's the second opinion I wanted. Just wanted to confirm that someone with a broader binutils thought the information loss would be OK.I am OK with it.
Thanks for your review. One side-effect of this patch set is support for RISC-V and 64-bit PowerPC for RTEMS.
Would someone mind committing this and https://sourceware.org/ml/binutils/2017-01/msg00318.html for me? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |