On Wed, 23 Aug 2023 at 03:37, Jose E. Marchesi <jose.marchesi@xxxxxxxxxx> 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.
>
Thank you for reminding me that. I will be more careful about this.
We certainly cannot rely on clang-specific behavior for this.
> > 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.
Thanks for confirming.
