On 7/29/23 9:54 PM, Jose E. Marchesi wrote:
On Sat, Jul 29, 2023 at 1:29 AM Jose E. Marchesi
<jose.marchesi@xxxxxxxxxx> wrote:
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.
I mainly had link-time relaxation in mind. The linker needs to know
what instructions are available (JMP32 or not) in order to decide what
to relax, and to what.
But the assembler has little choice when the jump target is >16bits.
It can use jmp32 or error.
When the assembler sees a jump instruction:
goto EXPR
there are several possibilities:
1. EXPR consists on a literal number like 1, -10 or 0xff, or an
expression that can be resolved during the first assembler pass (like
8 * 64). The numerical result is interpreted as number of 64-bit
words minus one. In this case, the assembler can immediately decide
whether the operand is >16 bits, relaxing to the jmp32 jump if cpu >=
v4 and unless -mno-relax is passed in the command line.
2. EXPR is a symbolic expression involving a symbol that can be resolved
during the second assembler pass. For example, `foo + 10'. In this
case, there are two possibilities:
2.1. The symbol is an absolute symbol. In this case the value is
interpreted as-such and no conversion is done by the assembler.
So if for example the user invokes the assembler passing
`--defsym foo=10', the assembled instruction is `ja 20'.
2.2. The symbol is a PC-relative or section-relative symbol. In this
case the value is interpreted as a byte offset (the assembler
takes care to transform offsets relative to the current section
into PC-relative offsets whenever necessary). This is the case
of labels. For these symbols, the BPF assembler converts the
value from bytes to number of 64-bit words minus one. So for
example for `ja done' where `done' has the value 256 bytes, the
assembled instruction is `ja 31'.
3. EXPR is a symbolic expression involving a symbol that cannot be
resolved during the second assembler pass. In this case, a
relocation for the 16-bit immediate field in the instruction is
generated in the assembled object. There is no R_BPF_64_16
relocation defined by BPF as of yet, so we are using
R_BPF_GNU_64_16=256, which as we agreed uses a high relocation number
to avoid collisions. Since gas is a standalone assembler, it seems
sensible to emit a relocation rather than erroing out in these
situations. ld knows how to handle these relocs when linking BPF
objects together.
I guess you're proposing to encode this e_flags in the text of asm ?
Special asm directive that will force asm to error or use jmp32?
GAS uses command-line options for that.
When GCC is invoked with -mcpu=v3, for example, it passes the
corresponding option to the assembler so it expects a BPF V3 assembly
program. In that scenario, if the user does a jump to an address that is
16bit in an inline asm, the assembler will error out,
because relaxing to jmp32 is not a possibility in V3. Ditto for
compiler options like -msdiv or -mjmp32, that both clang and GCC
support.
I don't know how clang configures its integrated assembler... I guess by
calling some function. But it is the same principle: if you tell clang
to generate v3 bpf and you include a header that uses a v4 instruction
(or overflown jump that would require relaxation) in inline asm, you
want an error.
If -mcpu=<version> is specified in the clang command line,
then the cpu <version> will be encoded in IR and will be
passed to the integrated assembler. And if you specify
-mcpu=v3 in the command line and your code has
cpu v4 inline assembly code, the compiler will error out.
Also as you mention the disassembler can look in the object to determine
which instructions shall be recognized and with insructions shall be
reported as <unknown>. Right now it is necessary to pass an explicit
option to the assembler, and the default is v4.
Disambiguating between unknown and exact insn kinda makes sense for disasm.
For assembler it's kinda weird. If text says 'sdiv' the asm should emit
binary code for it regardless of asm directive.
Unless configured to not do so? See above.
It seems e_flags can only be emitted by assembler.
Like if it needs to use jmp32 it will add EF_BPF_JMP32.
Yep.
Still feels that we can live without these flags, but not a bad
addition.
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.
As far as flag names, let's use EF_ prefix. I think it's more canonical.
And single 0xF is probably enough for cpu ver.
Agreed.
