From: Paul Brook <paul@codesourcery.com>
To: binutils@sourceware.org
Cc: Julian Brown <julian@codesourcery.com>,
binutils@sources.redhat.com,
Richard Earnshaw <Richard.Earnshaw@arm.com>
Subject: Re: [PATCH, ARM]: Fix diagnostics & disallow ARM instructions on V7M cores
Date: Fri, 12 May 2006 05:49:00 -0000 [thread overview]
Message-ID: <200605112321.35247.paul@codesourcery.com> (raw)
Message-ID: <20060512054900.WrMz8VMU-EiniUs5OMYZV5MZQJ_39e_Fke-VBrgMEH8@z> (raw)
In-Reply-To: <4463AB5D.6070108@codesourcery.com>
On Thursday 11 May 2006 22:23, Julian Brown wrote:
> + #define THUMB_ONLY (ARM_EXT_V7 | ARM_EXT_V7M)
> + #define THUMB_ONLY_EXCEPT (ARM_EXT_V7A | ARM_EXT_V7R)
I don't think these are necessary. In opcode_select we already have:
if (!ARM_CPU_HAS_FEATURE (cpu_variant, arm_ext_v1))
as_bad (_("selected processor does not support ARM opcodes"));
That condition should be ok whenever we need to check for a Thumb-only core.
> *************** md_begin (void)
> *** 18396,18401 ****
> --- 18417,18424 ----
>
> ARM_MERGE_FEATURE_SETS (cpu_variant, *mcpu_cpu_opt, *mfpu_opt);
>
> + autoselect_thumb_from_cpu_variant ();
> +
> arm_arch_used = thumb_arch_used = arm_arch_none;
Defaulting to thumb mode if a Thumb only core is specified on the commandline
ok I guess, however...
> #if defined OBJ_COFF || defined OBJ_ELF
> *************** s_arm_cpu (int ignored ATTRIBUTE_UNUSED)
> *** 19457,19462 ****
> --- 19480,19486 ----
> selected_cpu_name[i] = 0;
> }
> ARM_MERGE_FEATURE_SETS (cpu_variant, *mcpu_cpu_opt, *mfpu_opt);
> + autoselect_thumb_from_cpu_variant ();
I don't think making .arch armv7 imply .thumb is a good idea.
If we do this we should also make .arch armv4 imply .arm.
Paul
next prev parent reply other threads:[~2006-05-11 22:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-12 2:08 Julian Brown
2006-05-12 5:39 ` Paul Brook [this message]
2006-05-12 5:49 ` Paul Brook
2006-05-12 14:54 ` Julian Brown
2006-05-12 21:25 ` Paul Brook
2006-05-12 22:16 ` Richard Earnshaw
2006-07-19 20:31 ` Julian Brown
2006-08-08 11:54 ` Nick Clifton
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=200605112321.35247.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=Richard.Earnshaw@arm.com \
--cc=binutils@sources.redhat.com \
--cc=binutils@sourceware.org \
--cc=julian@codesourcery.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).