Re: GCC and binutils support for BPF V4 instructions

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

> On Sat, Jul 29, 2023 at 9:54 PM Jose E. Marchesi
> <jose.marchesi@oracle.com> wrote:
>>
>> The individual flags... I am not sure, other arches have them, but maybe
>> having them in BPF doesn't make much sense and it is not worth the extra
>> complication and wasted bits in e_flags.  How realistic is to expect
>> that some kernel may support a particular version of the BPF ISA, and
>> also have support for some particular instruction from a later ISA as
>> the result of a backport or something?  Not for me to judge... I was
>> already bitten by my utter ignorance on kernel business when I added
>> that silly useless -mkernel=VERSION option to GCC 8-)
>>
>> What I am pretty sure is that we will need something like EF_BPF_CPUVER
>> if we are ever gonna support relaxation in any linker external to
>> libbpf, and also to detect (and error/warn) when several objects with
>> different BPF versions are linked together.
>
> Ok. Let's start with EF_BPF_CPUVER 0xF
> and not waste bits on individual instructions, as you said.
> When kernel backports are done the patches are sent together.
> It wouldn't be wise to backport SDIV without JMP32, for example.
> git history will get screwed up and further backports will be a pain.
> The risk of untested combinations increases, etc.
> I think it's safe to assume that a given kernel will support either v3
> or v4.

This is good to know.  Thanks for explaining.

> The kernel version doesn't matter, of course :)

Yeah GCC no longer supports -mkernel :P

Allright, so I just pushed a binutils patch for elf.h, the disassembler,
the assembler and readelf:

  https://sourceware.org/pipermail/binutils/2023-July/128723.html

Note that the ISA version selection logic in the disassembler is:

1. If the user specifies an explicit version (v1, v2, v3, v4) then use
   it.

2. Otherwise, use the EF_BPF_CPUVER bits in the ELF header to derive the
   version to use:

   2.1. If the CPUVER is zero, then use the latest supported version
        (currently v4).  This is for backwards compability.

   2.2. Else, if CPUVER is one of the supported versions by the
        disassembler (currently 1, 2, 3 or 4) then use it.

   2.3. Else, emit an error "unknown BPF CPU version %d".

Maybe 2.3 should be a warning instead of an error...