[llvm-dev] llvm-mc assembler, GNU as, and pc-relative branches for Arm/AArch64/Mips

[Peter Smith via llvm-dev]

Hello Alex,

> 1) Is this an intentional difference in behaviour and just something assembly
> authors should live with?

I can't speak for the intent of the original author, although in Arm
and AArch64 a branch to a number is not well specified and it is
pretty much implementation defined how an assembler copes with it. For
example in the Arm ARM Use of labels in UAL instruction syntax: "B,
BL, and BLX (immediate). The assembler syntax for these instructions
always specifies the label of the instruction that they branch to".
The original Arm proprietary assembler armasm creates an absolute
symbol with a value of the immediate and gas may have decided to
follow suite.

> 2) If not, is there any interest in resolving it? Obviously I can file bugs on
> bugzilla.

For Arm/AArch64, practically speaking I've not seen a branch to number
used outside of an assembler test suite. In embedded systems branching
to an address that is defined in some ROM/Flash defined outside of the
current program is common. The usual way to handle this in the
toolchain is to branch to an external symbol that can be defined as
absolute in a different file or via some link time mechanism. This was
more maintainable than branching directly to the address in the
assembler code and worked with C code as well.

My personal opinion is that matching gas is desirable, but in this
case fixing it is probably more trouble than it is worth. Outside of
some horrific program that uses macros to construct the addresses at
assembly time; I'd think that it would be simple to rewrite the
portion of the program to use a symbol. It is worth noting that
although Arm And AArch64 have similar branch instructions (all
immediates are offsets) the GNU assembler has chosen to handle the
cases differently.

> 3) Is anyone interested in collaborating on better automated tooling for
> comparing the LLVM MC assembler and GNU as? Or even better, already have
> tooling help with this that might be open sourced? Automatically finding
> problems such as the assembly parsing issue described in Google's recent
> LLVMDevMeeting keynote <https://youtu.be/6l4DtR5exwo?t=10m44s> would be great.
>

I'd be interested in seeing it, although I don't know whether I'll be
able to dedicate a lot of time to it.

Peter