* BTF_KIND_FWD enums
@ 2020-07-28 20:56 Giuliano Procida
2020-07-29 7:09 ` Yonghong Song
0 siblings, 1 reply; 3+ messages in thread
From: Giuliano Procida @ 2020-07-28 20:56 UTC (permalink / raw)
To: Yonghong Song; +Cc: linux-kernel
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
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
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)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: BTF_KIND_FWD enums
2020-07-28 20:56 BTF_KIND_FWD enums Giuliano Procida
@ 2020-07-29 7:09 ` Yonghong Song
2020-07-29 8:44 ` Giuliano Procida
0 siblings, 1 reply; 3+ messages in thread
From: Yonghong Song @ 2020-07-29 7:09 UTC (permalink / raw)
To: Giuliano Procida; +Cc: linux-kernel
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.
> 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?
>
> 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)
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: BTF_KIND_FWD enums
2020-07-29 7:09 ` Yonghong Song
@ 2020-07-29 8:44 ` Giuliano Procida
0 siblings, 0 replies; 3+ messages in thread
From: Giuliano Procida @ 2020-07-29 8:44 UTC (permalink / raw)
To: Yonghong Song; +Cc: linux-kernel
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)
> >
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-07-29 8:44 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-28 20:56 BTF_KIND_FWD enums Giuliano Procida
2020-07-29 7:09 ` Yonghong Song
2020-07-29 8:44 ` Giuliano Procida
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.