linux-kernel - Re: [PATCH v2] libbpf: add GCC support for bpf_tail_call

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAADnVQL3HpDVUD3FHhLYqUjZ32K1pd5e6YCLBRsMVdiWc-+CCg@mail.gmail.com>
Date:   Sat, 10 Sep 2022 11:37:39 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     "Jose E. Marchesi" <jose.marchesi@...cle.com>
Cc:     James Hilliard <james.hilliard1@...il.com>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>,
        "Jose E. Marchesi" <jemarch@....org>,
        David Faust <david.faust@...cle.com>,
        bpf <bpf@...r.kernel.org>, Andrii Nakryiko <andrii@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <martin.lau@...ux.dev>,
        Song Liu <song@...nel.org>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        Stanislav Fomichev <sdf@...gle.com>,
        Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Tom Rix <trix@...hat.com>, LKML <linux-kernel@...r.kernel.org>,
        clang-built-linux <llvm@...ts.linux.dev>,
        elena.zannoni@...cle.com
Subject: Re: [PATCH v2] libbpf: add GCC support for bpf_tail_call_static

On Sat, Sep 10, 2022 at 1:43 AM Jose E. Marchesi
<jose.marchesi@...cle.com> wrote:
>
> 2) If/when we support the C-like assembly syntax in GCC,

Thank you for considering supporting the standard BPF assembly
syntax in GCC.
I agree that C-like asm looks unusual.
The main reason to pick that style was the ease of understanding
and to avoid gnu vs intel asm order confusion.
We didn't want to deal with question whether 'mov r1, r2'
means r1->r2 or r2->r1. The C style asm r1=r2 is unambiguous.