This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH][ARM][1/2] Cleanup mixed use of "cpu_variant" and selected_cpu"
- From: Jiong Wang <jiong dot wang at arm dot com>
- To: Will Newton <will dot newton at linaro dot org>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Thu, 14 Aug 2014 14:52:30 +0100
- Subject: Re: [PATCH][ARM][1/2] Cleanup mixed use of "cpu_variant" and selected_cpu"
- Authentication-results: sourceware.org; auth=none
- References: <53EC7B48 dot 5030507 at arm dot com> <CANu=DmjZPLOw1hksFbWNuzLkyX5gU-L6gUGPc7wPfQ-RT+fRMw at mail dot gmail dot com>
On 14/08/14 11:03, Will Newton wrote:
On 14 August 2014 10:03, Jiong Wang <email@example.com> wrote:
currently, gas for arm32 have several variables to track cpu features:
and there are some wrong usage of cpu_variant and selected_cpu which
I checked the log, there was cpu_variant only, but later a new variable
was introduced for TAG_cpu attribute generation only, since then people
use them in a mixed way.
for selected_cpu, its value depends on arch/cpu options or directives, if
them found, then its default value is zero.
while for cpu_variant, its default value is a mask contains all features,
and will be
updated to the value of selected_cpu *if the value of selected_cpu is not
so if no arch/cpu options/directives specified, then cpu_variant *accept*
while *selected_cpu* reject everything.
then if the code in parsing stage use cpu_variant, it will accept some
reject them in later fixup stage silently if this is not a error/warning
is a *logic error* affect correctness which should be fixed.
for example, given the following .s
.type entry, %function
blx label <=== A
.type label, %function
.type label2, %function
.type label3, %function
as -o 1.o 1.s
objdump -d 1.o
0: f7ff fffe bl 0 <entry>
at location A, a detected it's a thumb->thumb blx, then we convert it to bl,
but the relocated
destination point to itself which is wrong. this bug is just caused by mixed
use of cpu_variant
this patch and the following tries to clean up all the wrong usage of
selected_cpu, to make
feature check be consistent in the assembler.
New variable usage
* the first patch tries the following variable renaming:
Why are we replacing "cpu" with "arch"? Most of the manipulations of
these variables include with word "cpu" so it seems strange to name
thanks for your comment.
it's OK to change "arch" back to "cpu".
my intention is to find idea names that help people know immediately
which one to use.
* the second patch update intended_arch based on the info we got
during parsing, and thus naturally fix this bug.
"parse_arch" are to be used during gas parsing stage, for example those
do_XXX encoder in tc-arm.c.
"intended_arch" are to be used during all stage after parsing.
new variable calculation logic is:
* intended_arch default to be arm_arch_none which is empty.
* intended_arch initialized to the value of arch if any of
them is specified by cmdline or directive.
* if (inteneded_arch not empty) then
parse_arch = intended_arch
parse_arch = accept_all
the idea behind is if none arch info specified by the user, then
we should be permissive in parsing stage, while be strict in later
fixup stage. because accept unsupported instructions in parsing stage
will normally cause ill-instruction exception on silicon which is
obvious for user to fix, while wrong relocations may introduce silent
bugs which is hard to hunt.
any comments on this ?
* config/tc-arm.c : Rename "cpu_variant" to "parse_arch",
"selected_cpu" to intended_arch", "selected_cpu_name" to