From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) by sourceware.org (Postfix) with ESMTPS id B0B9F3858D20 for ; Wed, 12 Jul 2023 07:38:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B0B9F3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-2b69dcf45faso106563131fa.0 for ; Wed, 12 Jul 2023 00:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689147527; x=1691739527; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=D7ow61B1AJRzELaYgV+s6SnoJOHXoQgFO1il5wQZEhc=; b=Q2W90Kx+2feSGOUZKV/ZrO6chLyW77BWkV9VS4hJSU/OoXGGJklPe3Fccg4FHKD8YG Xrsc8v80YsFreQiIhLU3y5j46sHskis2PWsyt4D9uWDysEUM7sCc1gHdUV6qIfJk6rrr C+sXXnKat6chbBWHKXQ3LYy5bX9bsT4yDi64vx5AmRdyaoDSrZOw0CGKu6j3ze4XT5tY W6HToMsvUUKl6Fhm/4lHMGwBPKIzV7Z8SaCu+Oc82rhCAqQpqXuHPpV3LOCVlBKnNKW4 x4J/5GS9SjlJZ3B0SeGRvtiMKYMwss3swfpIFYdsuMmO8uDqELwy9ka60TvxNmnRZIze EPSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689147527; x=1691739527; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=D7ow61B1AJRzELaYgV+s6SnoJOHXoQgFO1il5wQZEhc=; b=M2F1pdTN4sw0H3jQ0OXpyQfUHvctG2vCDEuUuc7JvEmnDqN0Gpp9e9q9kavX2qjMgV Qn2ictTdNplizL3itEyUqxjJ64DZ196PKId9F7V1GekrBlql1ZSogv/bSroTO71dtpps Ztiq5J+B/NNRTSEvnXpupAMT822gwF5nqc0+AaUgtqXEYyej129DWXZ9dZyPg8NwmJDU BfT4NTYeQmzUoC/1zZe4rJ+c2zIozJRyuAlNfod2WSj7v3HUlYT4uYazU7rVEYmNeROu H7N6ZDEztCmLwwLgYDWqwo31iVSjIjLvHBiu7blYmTJCKKz1Cb2FXxQR/0MWwub9EHR3 VQHQ== X-Gm-Message-State: ABy/qLZCSMvAFwymDInbYA+0lfpVOoEUB2Qy/b4/Ld+iBsNUS03tzBHw IWyeQQykiB7AjVEynD5tXW93mNDAJlV+78BHqpz0z8i5 X-Google-Smtp-Source: APBJJlEN28e0Dt4s9EQegkk+QYb2OFglf+hMh85cEkYpwNh+76eOP7BW28dndmE1A7WvCUbQN2aKURUwNVmpv9MrsVk= X-Received: by 2002:a2e:9dd5:0:b0:2b6:f8d0:7d3d with SMTP id x21-20020a2e9dd5000000b002b6f8d07d3dmr15217519ljj.49.1689147526798; Wed, 12 Jul 2023 00:38:46 -0700 (PDT) MIME-Version: 1.0 References: <20230711215716.12980-1-david.faust@oracle.com> In-Reply-To: <20230711215716.12980-1-david.faust@oracle.com> From: Richard Biener Date: Wed, 12 Jul 2023 09:38:22 +0200 Message-ID: Subject: Re: [PATCH 0/9] Add btf_decl_tag C attribute To: David Faust Cc: gcc-patches@gcc.gnu.org, jose.marchesi@oracle.com, yhs@meta.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, Jul 11, 2023 at 11:58=E2=80=AFPM David Faust via Gcc-patches wrote: > > Hello, > > This series adds support for a new attribute, "btf_decl_tag" in GCC. > The same attribute is already supported in clang, and is used by various > components of the BPF ecosystem. > > The purpose of the attribute is to allow to associate (to "tag") > declarations with arbitrary string annotations, which are emitted into > debugging information (DWARF and/or BTF) to facilitate post-compilation > analysis (the motivating use case being the Linux kernel BPF verifier). > Multiple tags are allowed on the same declaration. > > These strings are not interpreted by the compiler, and the attribute > itself has no effect on generated code, other than to produce additional > DWARF DIEs and/or BTF records conveying the annotations. > > This entails: > > - A new C-language-level attribute which allows to associate (to "tag") > particular declarations with arbitrary strings. > > - The conveyance of that information in DWARF in the form of a new DIE, > DW_TAG_GNU_annotation, with tag number (0x6000) and format matching > that of the DW_TAG_LLVM_annotation extension supported in LLVM for > the same purpose. These DIEs are already supported by BPF tooling, > such as pahole. > > - The conveyance of that information in BTF debug info in the form of > BTF_KIND_DECL_TAG records. These records are already supported by > LLVM and other tools in the eBPF ecosystem, such as the Linux kernel > eBPF verifier. > > > Background > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The purpose of these tags is to convey additional semantic information > to post-compilation consumers, in particular the Linux kernel eBPF > verifier. The verifier can make use of that information while analyzing > a BPF program to aid in determining whether to allow or reject the > program to be run. More background on these tags can be found in the > early support for them in the kernel here [1] and [2]. > > The "btf_decl_tag" attribute is half the story; the other half is a > sibling attribute "btf_type_tag" which serves the same purpose but > applies to types. Support for btf_type_tag will come in a separate > patch series, since it is impaced by GCC bug 110439 which needs to be > addressed first. > > I submitted an initial version of this work (including btf_type_tag) > last spring [3], however at the time there were some open questions > about the behavior of the btf_type_tag attribute and issues with its > implementation. Since then we have clarified these details and agreed > to solutions with the BPF community and LLVM BPF folks. > > The main motivation for emitting the tags in DWARF is that the Linux > kernel generates its BTF information via pahole, using DWARF as a source: > > +--------+ BTF BTF +----------+ > | pahole |-------> vmlinux.btf ------->| verifier | > +--------+ +----------+ > ^ ^ > | | > DWARF | BTF | > | | > vmlinux +-------------+ > module1.ko | BPF program | > module2.ko +-------------+ > ... > > This is because: > > a) pahole adds additional kernel-specific information into the > produced BTF based on additional analysis of kernel objects. > > b) Unlike GCC, LLVM will only generate BTF for BPF programs. > > b) GCC can generate BTF for whatever target with -gbtf, but there is no > support for linking/deduplicating BTF in the linker. > > In the scenario above, the verifier needs access to the pointer tags of > both the kernel types/declarations (conveyed in the DWARF and translated > to BTF by pahole) and those of the BPF program (available directly in BTF= ). > > > DWARF Representation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > As noted above, btf_decl_tag is represented in DWARF via a new DIE > DW_TAG_GNU_annotation, with identical format to the LLVM DWARF > extension DW_TAG_LLVM_annotation serving the same purpose. The DIE has > the following format: > > DW_TAG_GNU_annotation (0x6000) > DW_AT_name: "btf_decl_tag" > DW_AT_const_value: > > These DIEs are placed in the DWARF tree as children of the DIE for the > appropriate declaration, and one such DIE is created for each occurrence > of the btf_decl_tag attribute on a declaration. > > For example: > > const int * c __attribute__((btf_decl_tag ("__c"), btf_decl_tag ("devic= emem"))); > > This declaration produces the following DWARF: > > <1><1e>: Abbrev Number: 2 (DW_TAG_variable) > <1f> DW_AT_name : c > <24> DW_AT_type : <0x49> > ... > <2><36>: Abbrev Number: 3 (User TAG value: 0x6000) > <37> DW_AT_name : (indirect string, offset: 0x4c): btf_decl_= tag > <3b> DW_AT_const_value : (indirect string, offset: 0): devicemem > <2><3f>: Abbrev Number: 4 (User TAG value: 0x6000) > <40> DW_AT_name : (indirect string, offset: 0x4c): btf_decl_= tag > <44> DW_AT_const_value : __c > <2><48>: Abbrev Number: 0 > <1><49>: Abbrev Number: 5 (DW_TAG_pointer_type) > ... > > The DIEs for btf_decl_tag are placed as children of the DIE for > variable "c". It looks like a bit of overkill, and inefficient as well. Why's the tags not referenced via the existing DW_AT_description? Iff you want new TAGs why require them as children for each DIE rather than referencing (and sharing!) them via a = DIE reference from a new attribute? That said, I'd go with DW_AT_description 'btf_decl_tag ("devicemem")'. But well ... Richard. > > BTF Representation > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > In BTF, BTF_KIND_DECL_TAG records convey the annotations. These records r= efer > to the annotated object by BTF type ID, as well as a component index whic= h is > used for btf_decl_tags placed on struct/union members or function argumen= ts. > > For example, the BTF for the above declaration is: > > [1] INT 'int' size=3D4 bits_offset=3D0 nr_bits=3D32 encoding=3DSIGNED > [2] CONST '(anon)' type_id=3D1 > [3] PTR '(anon)' type_id=3D2 > [4] DECL_TAG '__c' type_id=3D6 component_idx=3D-1 > [5] DECL_TAG 'devicemem' type_id=3D6 component_idx=3D-1 > [6] VAR 'c' type_id=3D3, linkage=3Dglobal > ... > > The BTF format is documented here [4]. > > > References > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > [1] https://lore.kernel.org/bpf/20210914223004.244411-1-yhs@fb.com/ > [2] https://lore.kernel.org/bpf/20211011040608.3031468-1-yhs@fb.com/ > [3] https://gcc.gnu.org/pipermail/gcc-patches/2022-May/593936.html > [4] https://www.kernel.org/doc/Documentation/bpf/btf.rst > > > David Faust (9): > c-family: add btf_decl_tag attribute > include: add BTF decl tag defines > dwarf: create annotation DIEs for decl tags > dwarf: expose get_die_parent > ctf: add support to pass through BTF tags > dwarf2ctf: convert annotation DIEs to CTF types > btf: create and output BTF_KIND_DECL_TAG types > testsuite: add tests for BTF decl tags > doc: document btf_decl_tag attribute > > gcc/btfout.cc | 81 ++++++++++++++++++- > gcc/c-family/c-attribs.cc | 23 ++++++ > gcc/ctf-int.h | 28 +++++++ > gcc/ctfc.cc | 10 ++- > gcc/ctfc.h | 17 +++- > gcc/doc/extend.texi | 47 +++++++++++ > gcc/dwarf2ctf.cc | 73 ++++++++++++++++- > gcc/dwarf2out.cc | 37 ++++++++- > gcc/dwarf2out.h | 1 + > .../gcc.dg/debug/btf/btf-decltag-func.c | 21 +++++ > .../gcc.dg/debug/btf/btf-decltag-sou.c | 33 ++++++++ > .../gcc.dg/debug/btf/btf-decltag-var.c | 19 +++++ > .../gcc.dg/debug/dwarf2/annotation-decl-1.c | 9 +++ > .../gcc.dg/debug/dwarf2/annotation-decl-2.c | 18 +++++ > .../gcc.dg/debug/dwarf2/annotation-decl-3.c | 17 ++++ > include/btf.h | 14 +++- > include/dwarf2.def | 4 + > 17 files changed, 437 insertions(+), 15 deletions(-) > create mode 100644 gcc/ctf-int.h > create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-decltag-func.c > create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-decltag-sou.c > create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-decltag-var.c > create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/annotation-decl-1.c > create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/annotation-decl-2.c > create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/annotation-decl-3.c > > -- > 2.40.1 >