On Wed, 8 Feb 2017, James Hogan wrote:
> When building for microMIPS we need to ensure that the assembler always
> knows that there is code at the target of a branch or jump. Commit
> 7170bdc77755 ("MIPS: Add return errors to protected cache ops")
> introduced a fixup path to protected_cache(e)_op() which does not meet
> this requirement. The fixup path jumps to the "2" label but we don't
> know what will be placed at that label since it's at the end of the
> inline asm. If the inline asm happens to be followed by an instruction
> manually encoded with .word or similar then the toolchain will not know
> that "2" labels code and linking will fail with:
>
> mips-img-linux-gnu-ld: arch/mips/mm/c-r4k.o: .fixup+0x0: Unsupported
> jump between ISA modes; consider recompiling with interlinking
> enabled.
That is not really the cause. The cause is the `.section' pseudo-op that
immediately physically follows, and which causes GAS to fix its current
state. Since by this point it hasn't seen an instruction any outstanding
labels that haven't been finalised will be marked as `object' (i.e. data).
So it doesn't really matter what follows the inline asm, an ISA mode
mismatch will always happen here.
The amount of infrastructure that would be required to have state saved
and then restored where applicable to "see through section switches" is
substantial enough for no one to have tried implementing it so far.
Consequently all places where a code label is immediately followed by one
of the section switch directives (technically, by the syntax rules of the
assembly language, such a label is attached to the directive), such as
`.section', `.previous', `.popsection', etc., need to have `.insn' added
to be treated correctly (arguably we could make them mark labels as
`function' instead, however I fear it may break something out there in a
subtler way as you won't get a similar error for data accesses and the
semantics has been like this since the introduction of MIPS16 support back
in 1996).
I suggest that you send an update with the description amended so as not
to confuse people about the actual cause. Overall, unless you have done
that already, I think it would be the best if our sources were reviewed
for any remaining places across the MIPS port where a code label is
followed by a section switch and `.insn' added there right away. It will
prevent people sneaking in new bad code by copying and pasting from the
wrong place.
I'll be happy to ack a patch with an updated description.
Maciej
