Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAGvU0H=AAPt0wSTh1dyb-aTnG9zeUY6U2uBkmi6K9Bvpuc9YAA@mail.gmail.com>
 <9d9a48e0-844d-8ba4-b839-92cb1af622ee@fb.com>
In-Reply-To: <9d9a48e0-844d-8ba4-b839-92cb1af622ee@fb.com>
From:   Giuliano Procida <gprocida@google.com>
Date:   Wed, 29 Jul 2020 09:44:05 +0100
Message-ID: <CAGvU0HmUnMq=7W=GhW+Mut9henBf5yDDgG7S2RfVFny7VdoUJQ@mail.gmail.com>
Subject: Re: BTF_KIND_FWD enums
To:     Yonghong Song <yhs@fb.com>
Cc:     linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi.

On Wed, 29 Jul 2020 at 08:09, Yonghong Song <yhs@fb.com> wrote:
>
>
>
> On 7/28/20 1:56 PM, Giuliano Procida wrote:
> > Hi.
> >
> > Re: https://github.com/torvalds/linux/commit/9d5f9f701b1891466fb3dbb1806ad97716f95cc3
> >
> > Both GCC and LLVM support forward-declared (a.k.a. incomplete) enums
> > as a language extension -
> > https://gcc.gnu.org/onlinedocs/gcc/Incomplete-Enums.html.
> >
> > (C++11 has a different notion of incomplete enum type - opaque enum
> > declaration - storage size is known but enumerators are not)
> >
> > Forward-declared enums feature in various places in kernel code and
> > allow the usual things to be done (passing around pointers to such).
> > I'm curious as to if and how they are they are handled by BTF and
> > whether a further change to btf_type is needed:
> >
> > 1. Use BTF_KIND_FWD, with another spare bit to allow up to 4 kinds of
> > forward-declaration; or
> > 2. use BTF_KIND_ENUM, kind_flag 0 and vlen 0 (as empty enums are
> > currently illegal C); or
>
> #2 above is the current way.
> -bash-4.4$ cat t.c
> enum H;
> enum H * func(enum H *arg) { return arg; }
> -bash-4.4$ clang -target bpf -S -g -O2 t.c
>
> -bash-4.4$
>
> The generated BTF enum type:
>
>          .long   1                               # BTF_KIND_ENUM(id = 2)
>          .long   100663296                       # 0x6000000
>          .long   0
>
> So vlen = 0 here indicates it is a forward declaration.
>

Thanks, that's all clear. There is a small risk that C will follow C++
and allow zero enumerators in the future.

>
> > 3. use BTF_KIND_ENUM, kind_flag 1 and vlen 0.
> >
> > If I had a working pahole -J, I'd test this myself. :-)
> >
> > $ cat /tmp/en.c
> > enum H;
> > enum H * fun(enum H * x) { return x; }
> > $ clang -Wall -Wextra -ggdb -c /tmp/en.c
> > $ build/pahole -J /tmp/en.o
> > Segmentation fault
> > $ build/pahole -J /dev/null
> > btf_elf__new: cannot get elf header.
> > ctf__new: cannot get elf header.
> > Segmentation fault
>
> -bash-4.4$ cat t.c
> enum H;
> enum H * func(enum H *arg) { return arg; }
> -bash-4.4$ ~/work/pahole/build/pahole --version
> v1.17
> -bash-4.4$ clang -Wall -Wextra -ggdb -c t.c
>
> -bash-4.4$ ~/work/pahole/build/pahole -JV t.o
> File t.o:
> [1] PTR (anon) type_id=2
> [2] ENUM H size=4 vlen=0
> [3] INT (anon) size=4 bit_offset=0 nr_bits=32 encoding=(none)
> [4] FUNC_PROTO (anon) return=1 args=(1 arg)
> [5] FUNC func type_id=4
>
> pahole also generates vlen=0 ENUM type to indicate it is a
> forward declaration.
>
> Maybe your pahole is too old?

I tried both master and v1.17. Perhaps my libdw (Debian 0.176-1.1) is
incompatible or some other library is too old.

Regards,
Giuliano.

> >
> > My interest here is that I helped add support for incomplete enums to
> > libabigail which we're using to monitor kernel ABIs.
> >
> > Regards,
> > Giuliano.
> >
> > (resend due to email address typo)
> >