Re: [PATCH bpf-next v2 00/14] Exceptions - 1/2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 8/22/23 3:07 PM, Jose E. Marchesi wrote:

On Wed, 9 Aug 2023 at 17:11, Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx> wrote:

[...]

Known issues
------------

  * Just asm volatile ("call bpf_throw" :::) does not emit DATASEC .ksyms
    for bpf_throw, there needs to be explicit call in C for clang to emit
    the DATASEC info in BTF, leading to errors during compilation.


Hi Yonghong, I'd like to ask you about this issue to figure out
whether this is something worth fixing in clang or not.
It pops up in programs which only use bpf_assert macros (which emit
the call to bpf_throw using inline assembly) and not bpf_throw kfunc
directly.

I believe in case we emit a call bpf_throw instruction, the BPF
backend code will not see any DWARF debug info for the respective
symbol, so it will also not be able to convert it and emit anything to
.BTF section in case no direct call without asm volatile is present.
Therefore my guess is that this isn't something that can be fixed in
clang/LLVM.

Besides, please keep in mind that GCC doens't have an integrated
assembler, and therefore relying on clang's understanding on the
instructions in inline assembly is something to avoid.

There are also options like the one below to work around it.
if ((volatile int){0}) bpf_throw();
asm volatile ("call bpf_throw");

I can confirm the above results in a BTF entry for bpf_throw with
bpf-unknown-none-gcc -gbtf.

Kumar, you are correct.
For clang, symbols inside 'asm volatile' statement or generally
inside any asm code (e.g., kernel .s files) won't generate an entry
in dwarf. The
  if ((volatile int){0}) bpf_throw();
will force a dwarf, hence btf, entry.

The unfortunately thing is the above code will generate redundant code
like
  0000000000000000 <foo>:
       0:       b7 01 00 00 00 00 00 00 r1 = 0x0
       1:       63 1a fc ff 00 00 00 00 *(u32 *)(r10 - 0x4) = r1
       2:       61 a1 fc ff 00 00 00 00 r1 = *(u32 *)(r10 - 0x4)
       3:       15 01 01 00 00 00 00 00 if r1 == 0x0 goto +0x1 <LBB0_2>
       4:       85 10 00 00 ff ff ff ff call -0x1

0000000000000028 <LBB0_2>:
       5:       85 10 00 00 ff ff ff ff call -0x1
       6:       b7 00 00 00 00 00 00 00 r0 = 0x0
       7:       95 00 00 00 00 00 00 00 exit

I am curious why in bpf_assert macro bpf_throw() kfunc cannot
be used?




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux