Re: GCC and binutils support for BPF V4 instructions

["Jose E. Marchesi" <jose.marchesi@oracle.com>]

>> On 7/28/23 9:41 AM, Jose E. Marchesi wrote:
>>> Hello.
>>> Just a heads up regarding the new BPF V4 instructions and their
>>> support
>>> in the GNU Toolchain.
>>> V4 sdiv/smod instructions
>>>    Binutils has been updated to use the V4 encoding of these
>>>    instructions, which used to be part of the xbpf testing dialect used
>>>    in GCC.  GCC generates these instructions for signed division when
>>>    -mcpu=v4 or higher.
>>> V4 sign-extending register move instructions
>>> V4 signed load instructions
>>> V4 byte swap instructions
>>>    Supported in assembler, disassembler and linker.  GCC generates
>>> these
>>>    instructions when -mcpu=v4 or higher.
>>> V4 32-bit unconditional jump instruction
>>>    Supported in assembler and disassembler.  GCC doesn't generate
>>> that
>>>    instruction.
>>>    However, the assembler has been expanded in order to perform the
>>>    following relaxations when the disp16 field of a jump instruction is
>>>    known at assembly time, and is overflown, unless -mno-relax is
>>>    specified:
>>>      JA disp16  -> JAL disp32
>>>      Jxx disp16 -> Jxx +1; JA +1; JAL disp32
>>>    Where Jxx is one of the conditional jump instructions such as
>>> jeq,
>>>    jlt, etc.
>>
>> Sounds great. The above 'JA/Jxx disp16' transformation matches
>> what llvm did as well.
>
> Not by chance ;)
>
> Now what is pending in binutils is to relax these jumps in the linker as
> well.  But it is very low priority, compared to get these kernel
> selftests building and running.  So it will happen, but probably not
> anytime soon.

By the way, for doing things like that (further object transformations
by linkers and the like) we will need to have the ELF files annotated
with:

- The BPF cpu version the object was compiled for: v1, v2, v3, v4, and

- Individual flags specifying the BPF cpu capabilities (alu32, bswap,
  jmp32, etc) required/expected by the code in the object.

Note it is interesting to being able to denote both, for flexibility.

There are 32 bits available for machine-specific flags in e_flags, which
are commonly used for this purpose by other arches.  For BPF I would
suggest something like:

#define EF_BPF_ALU32  0x00000001
#define EF_BPF_JMP32  0x00000002
#define EF_BPF_BSWAP  0x00000004
#define EF_BPF_SDIV   0x00000008
#define EF_BPF_CPUVER 0x00FF0000

>>
>>> So I think we are done with this.  Please let us know if these
>>> instructions ever change.
>>> Relevant binutils bugzillas (all now resolved as fixed):
>>> * Make use of long range calls by relaxation (jal/gotol):
>>>    https://sourceware.org/bugzilla/show_bug.cgi?id=30690
>>> Relevant GCC bugzillas (all now resolved as fixed):
>>> * Make use of signed-load instructions:
>>>    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110782
>>>    * Make use of signed division/modulus:
>>>    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110783
>>> * Make use of signed mov instructions:
>>>    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110784
>>> * Make use of byte swap instructions:
>>>    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110786
>>> Salud!
>>>