On Sun, Jul 30, 2023 at 2:06 PM Jose E. Marchesi <jose.marchesi@xxxxxxxxxx> wrote: > > > > On Sat, Jul 29, 2023 at 9:54 PM Jose E. Marchesi > > <jose.marchesi@xxxxxxxxxx> 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... Warn is probably better. Older disasm should still print what it knows about from newer ELF. Unknown insns from cpu=v5 will be 'unknown'. That's better than no output at all.
