currently, gas for arm32 have several variables to track cpu features:
cpu_variant
selected_cpu
arm_arch_used
thumb_arch_used
and there are some wrong usage of cpu_variant and selected_cpu which
actually affect
binary correctness.
I checked the log, there was cpu_variant only, but later a new variable
"selected_cpu"
was introduced for TAG_cpu attribute generation only, since then people
start to
use them in a mixed way.
for selected_cpu, its value depends on arch/cpu options or directives, if
none of
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
zero*.
so if no arch/cpu options/directives specified, then cpu_variant *accept*
everything
while *selected_cpu* reject everything.
then if the code in parsing stage use cpu_variant, it will accept some
features, but
reject them in later fixup stage silently if this is not a error/warning
report. this
is a *logic error* affect correctness which should be fixed.
for example, given the following .s
.syntax unified
.thumb
.type entry, %function
.global entry
entry:
blx label <=== A
.type label, %function
label:
bx lr
.arm
.type label2, %function
label2:
blx label3
.type label3, %function
label3:
bx lr
as -o 1.o 1.s
objdump -d 1.o
00000000 <entry>:
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
and selected_cpu.
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:
s/cpu_variant/parse_arch/
s/selected_cpu_name/intended_arch_name/
s/selected_cpu/intended_arch/