On Fri, Jul 28, 2023 at 11:01 AM Jose E. Marchesi <jose.marchesi@xxxxxxxxxx> wrote: > > > >> 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 Interesting idea. I don't mind, but what are we going to do with this info? I cannot think of anything useful libbpf could do with it. For other archs such flags make sense, since disasm of everything to discover properties is hard. For BPF we will parse all insns anyway, so additional info in ELF doesn't give any additional insight.
