Message ID | 20221207205734.9287-2-david.faust@oracle.com |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C5A32390CE8D for <patchwork@sourceware.org>; Wed, 7 Dec 2022 20:58:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C5A32390CE8D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1670446738; bh=uomGS3HHPPEYME3VLhatSv1DlwNHuVcfwoiMB4SVST4=; h=To:Cc:Subject:Date:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=NmCr2PWSVghodkjx9evVSFzrskxTj/ANLjhRVVogQVD1ZWoOqNlxY6hL8D96uvI+Z LzPdjGY9oZf92NUvjXs3/eE7HiMK5IlXEoVpdhAyHFQ363jbUALExfQnmubgV00JAR /6pDDlu1edl+ceZLVPSNGGZAMit9typWQQpIx+z8= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32]) by sourceware.org (Postfix) with ESMTPS id 6EB2138B6341 for <gcc-patches@gcc.gnu.org>; Wed, 7 Dec 2022 20:57:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6EB2138B6341 Received: from pps.filterd (m0246617.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2B7J6CDS021939 for <gcc-patches@gcc.gnu.org>; Wed, 7 Dec 2022 20:57:53 GMT Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.appoci.oracle.com [138.1.37.129]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3maubahe4u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <gcc-patches@gcc.gnu.org>; Wed, 07 Dec 2022 20:57:53 +0000 Received: from pps.filterd (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.17.1.5/8.17.1.5) with ESMTP id 2B7J2Lh5021720 for <gcc-patches@gcc.gnu.org>; Wed, 7 Dec 2022 20:57:52 GMT Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2107.outbound.protection.outlook.com [104.47.70.107]) by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 3maa8gexs2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <gcc-patches@gcc.gnu.org>; Wed, 07 Dec 2022 20:57:52 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y6x8/c8QaoU5nteWPf9lljLBZhJKIkRD5rq6MJ6SnQ+EP1Fnn/+0W7lBvKvHVAn/PMuIOr4s1wGNVYDlzsRz1kWiamceUlQbStVJ+r7SfeQzBrEjC6iHDyxs1JRwI+1MfWwSXHHkhcB36xVSp3+BAAFi3/ddEAhXr+ZLcEUD/qau0JDsWCFxk1yFNH7YdDP1EMStETXPxDMsw+qhX6N5BFsoNk1Kb4zXihZOtMWgtF79Ba9KDBOdBrMnWvbV4GaqytR7HxEiiYULLaAwY/22V3y5HVNNpNAj7PK3nmxmEqy3vUU+M5H1VEeuxV9w6ioWL+Rpw8LW+MkrxIuFx1uXRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uomGS3HHPPEYME3VLhatSv1DlwNHuVcfwoiMB4SVST4=; b=GYQz3M/x1MRKq7j+4j9FVIBcoQ0gLeJ8Oro8rI8R+aljPYvh3aA3XI2tIEZOyVRtiP5cO2z1qfglm4s4spNADXvUiAdy7CsC/qTtxtBGGLs5W6m1s0FOCqJsr7MNxNpIIXhX/9OXIjKCZzsDhX2tNhezsdieatx/eI7hEjjAHmKGOzYvwMwXxEFEI36DzgHvDjze7fvyTYjmChtA6qLnr3dJ86tmkpkFzYiDHX87k+l9n3152o0la7Ux2qcU1TMCfYlnIUQsRm8jpT4/BNY3L/W94RJGXcpfYkmImlE4C0rne+adZsRv7l3EiQMxiLgMcoYVra/tfBNjTpk7X0XY0A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none Received: from MN2PR10MB3213.namprd10.prod.outlook.com (2603:10b6:208:131::33) by DM6PR10MB4330.namprd10.prod.outlook.com (2603:10b6:5:21f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.14; Wed, 7 Dec 2022 20:57:50 +0000 Received: from MN2PR10MB3213.namprd10.prod.outlook.com ([fe80::dd41:a422:5763:8848]) by MN2PR10MB3213.namprd10.prod.outlook.com ([fe80::dd41:a422:5763:8848%7]) with mapi id 15.20.5880.014; Wed, 7 Dec 2022 20:57:50 +0000 To: gcc-patches@gcc.gnu.org Cc: indu.bhagat@oracle.com, jose.marchesi@oracle.com Subject: [PATCH 1/3] btf: add 'extern' linkage for variables [PR106773] Date: Wed, 7 Dec 2022 12:57:32 -0800 Message-Id: <20221207205734.9287-2-david.faust@oracle.com> X-Mailer: git-send-email 2.38.1 In-Reply-To: <20221207205734.9287-1-david.faust@oracle.com> References: <20221207205734.9287-1-david.faust@oracle.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SJ0PR05CA0112.namprd05.prod.outlook.com (2603:10b6:a03:334::27) To MN2PR10MB3213.namprd10.prod.outlook.com (2603:10b6:208:131::33) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: MN2PR10MB3213:EE_|DM6PR10MB4330:EE_ X-MS-Office365-Filtering-Correlation-Id: 8d07e15f-7c86-437a-b6c9-08dad895b391 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JWyStInh1DCog0MrKmf25TNaARPl1K6h5mNqgbBiIb4M9J+4wZHM1CAcUNxTCwgTDHHZ6sXm8JE81mbMtmmFqoud0CGSmCw/DsXBt7rnqMq3Suno0QR8IGZ7cbjngKE0FfxN75dhOZxSQ15I5gnOqpYTZ95j1uHVlSvddLbSXzvz/YEzXetWbg7IogtLq/EFH3FRB8C4btFvEqSUGFJFxrr/JxVLK4acnxPIWzgJ+uWtTP85M6Cw5CpB6/l4ThA+E9VZmNuwQIxb/363iynusR95RRk+KE13ZIoThOjNbJmS2zJeLBW0PjrJbE/Mcnu8RWPMXpLxNu3CB50SZbvqQTBa8SDOstjAvClkU6iQm2fkwqgc/71efpuvK5+EcWys/Gq0COFWc12VRxxCDBq27mphUZK2Sigvn5eoKy2aXYjPu2Ryf0IkJc99y2bzkwD3DYMhm5jabXF+evjud3/aTw4MFQvw7PKTsgZtpXAjbQpItJuTHVHeoLnfVcpnQi2CJlmZ9cGuVlFeKFnDZKftCkZfMuP02ar5qBvEjopZzzAQZ4NTUNivyn3m0B60W0JJmW3YWvfuUs0PqCHh/gO8u+FfBAaIwXJC3seOLoXjj/vousy0f9hM+1D8u66mxIGCLosXZRgAssS/VeXRLVubxsEQ6JUd0pmNeBQATV0IQ+A= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR10MB3213.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(136003)(346002)(396003)(366004)(39860400002)(376002)(451199015)(41300700001)(86362001)(8936002)(478600001)(44832011)(2616005)(66476007)(66946007)(107886003)(6666004)(84970400001)(5660300002)(1076003)(66556008)(8676002)(38100700002)(4326008)(6486002)(6512007)(6506007)(83380400001)(26005)(186003)(316002)(36756003)(2906002)(6916009); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: iWExoQGiDFLQsO4Z/WpAiTR3YQia9V2rAd+nULQOfoCbQJ3jz3ZcyXKUwXnEJvJj/0Uy2BGjza/s9pFyRsbzvGv7GYlRP5bWZO5vIiWd//vglbuAIsUlpW0gj3SGfO9uuei0K4UW5h6VLc1yKKm9deKt+UI3AmK58c74i5N1KiibSN74k4UCWYwwFXi1J7PoUP6kViEo7IhZaU4X3aJyB2IbiAV/pin5gyiU2IAw99GyPT2KODgE8jjHbXg8VkcITX3IOJ4Ud3kdxa4n75+z+K/Ea5BVB+mRWsT0wGS9VrEJFpBucaucumqcYslSLHEVg6i+dpOk3T696Y7cAvMHU3J4uxNW9YioHJ6Wdnso+/R4Ib9KMFR/n01pQxLRSBycnlH3su232Ccda89fNgNS3pw1ZMMOMdD+fRuHU6kb2bAFo5MxqNHjgFCUYh+vMqtMdtooI24TV0M23sAY79nkT1nirAust5JcHXlhA9rHgq7BlWPOMwbN8zPhQqfAL3QdJ+SB6siKEPAf5DXieRZ2u696uKSE3lj9iaReIowlQsxWrmjafrESQP1yF2IRv9MvHF32WvuMqc3fK5Q7867AQ0+24Vz8oEjxn+MBg8STSktVtsDWzYnMKG7FwjhMC/frSLg+WaoSk0gkwyYPMdTT2utDTVXiWnE8Coa6C8hMOj7lqOUSHPsitDR3uIIe1iegSpmEyhxRZ+8O/Nhs/RRScj1zuJiQZs+cwNtWz2/bQimd7jBhBTX0iNchFVNoTOHgi263tXT94mEpLN112iMpjy4arMRhjE9RTScgjqXTvQmuHerkfRo7LvCxz1BNXIF7whuqGhT4t1ImvvLDK1s4UAoll/fWqXs9xFa51+YABWhfXExyRkmeLQ8DEIal2i8CPSqzaGQ/tGlcIj2jvZXZK4spAeecL7U+cdMjtpXQWbxh03OMiHNrlEBiWGGh5qAwVZctZL5UnkNCcrdPoEEL4yNOKFUSX9joLi+85TLorY7NEdS5OgkqRHC4ZslNxkxdUTFpXrk/WO79jCJzCPHFon0Xq3b49D9CwN4YRqpVOa7v+MiK8B4hx7XLUTRy9PJuuLqP6PdBX6vYJD45aVmXAy671dd6fNerWuGq0nnUctyvwXRnSFV0YK7TKiQ1RagdH0w9wMOGOQDUkkIW6Z7Y9tip1itoQSk+N89e1vEh6r5AJGGp3rYCnZ/nlMZC91y+T6e7Ba+0yKSewbZjX5+cOGd9YnsPOCMBr1La5vGHL0/f3TA4+qCy/ciRqhLQqPNfKrGsQ+29w/wEp+jTEt9RkBhjG528EvKoAjluZiAy5AojgMV9cIx0Mayv4wGJl07W9kvyQbUUxSfYV9qMC8DP51puw+mR20ob9S3/cEROMqK/egIVbVq40JzUqVhG4egXiKhN64sG4vK+SRlWSsVllJgnFQWCsAUYEcYtOjs5mJjy7IKD4yl3ncziNpFvcsARIeGE6N8umU6wBRCn0gARr/5mqdzy61JVXHdcHvboJFKYjyYZuaKt5ipNm7KXFkBdWqFebJfxUcoFfO2w9KJeIc6fxJM9mk/fZCZRocck2Wt7HpW5ZpVgXF6SJc+QuCfk X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8d07e15f-7c86-437a-b6c9-08dad895b391 X-MS-Exchange-CrossTenant-AuthSource: MN2PR10MB3213.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2022 20:57:50.3556 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Vv8N9DnZui86bDoonnz2WBs3o+47Agja/7Cy2wfAeDdXV9WkCerCsq/Y3Vtkn1+F/W1Xzm5G79kEevyRBTR9GA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR10MB4330 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-12-07_09,2022-12-07_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 bulkscore=0 suspectscore=0 phishscore=0 malwarescore=0 mlxscore=0 spamscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2212070176 X-Proofpoint-GUID: lqV9nxJpZCRxD-sKzE1jk00mGlVg7qzL X-Proofpoint-ORIG-GUID: lqV9nxJpZCRxD-sKzE1jk00mGlVg7qzL X-Spam-Status: No, score=-13.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: David Faust via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: David Faust <david.faust@oracle.com> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
btf: fix BTF for extern items [PR106773]
|
|
Commit Message
David Faust
Dec. 7, 2022, 8:57 p.m. UTC
Add support for the 'extern' linkage value for BTF_KIND_VAR records, which is used for variables declared as extern in the source file. PR target/106773 gcc/ * btfout.cc (BTF_LINKAGE_STATIC): New define. (BTF_LINKAGE_GLOBAL): Likewise. (BTF_LINKAGE_EXTERN): Likewise. (btf_collect_datasec): Mark extern variables as such. (btf_asm_varent): Accomodate 'extern' linkage. gcc/testsuite/ * gcc.dg/debug/btf/btf-variables-4.c: New test. include/ * btf.h (struct btf_var): Update comment to note 'extern' linkage. --- gcc/btfout.cc | 9 ++++++- .../gcc.dg/debug/btf/btf-variables-4.c | 24 +++++++++++++++++++ include/btf.h | 2 +- 3 files changed, 33 insertions(+), 2 deletions(-) create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c
Comments
Hi David, On 12/7/22 12:57, David Faust wrote: > Add support for the 'extern' linkage value for BTF_KIND_VAR records, > which is used for variables declared as extern in the source file. > > PR target/106773 > > gcc/ > > * btfout.cc (BTF_LINKAGE_STATIC): New define. > (BTF_LINKAGE_GLOBAL): Likewise. > (BTF_LINKAGE_EXTERN): Likewise. > (btf_collect_datasec): Mark extern variables as such. > (btf_asm_varent): Accomodate 'extern' linkage. > > gcc/testsuite/ > > * gcc.dg/debug/btf/btf-variables-4.c: New test. > > include/ > > * btf.h (struct btf_var): Update comment to note 'extern' linkage. > --- > gcc/btfout.cc | 9 ++++++- > .../gcc.dg/debug/btf/btf-variables-4.c | 24 +++++++++++++++++++ > include/btf.h | 2 +- > 3 files changed, 33 insertions(+), 2 deletions(-) > create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c > > diff --git a/gcc/btfout.cc b/gcc/btfout.cc > index aef9fd70a28..a1c6266a7db 100644 > --- a/gcc/btfout.cc > +++ b/gcc/btfout.cc > @@ -66,6 +66,10 @@ static char btf_info_section_label[MAX_BTF_LABEL_BYTES]; > > #define BTF_INVALID_TYPEID 0xFFFFFFFF > > +#define BTF_LINKAGE_STATIC 0 > +#define BTF_LINKAGE_GLOBAL 1 > +#define BTF_LINKAGE_EXTERN 2 > + I was about to suggest to rename these to use the same name as used in the kernel btf.h. What is used there is: BTF_VAR_STATIC = 0, BTF_VAR_GLOBAL_ALLOCATED = 1, BTF_VAR_GLOBAL_EXTERN = 2, But after looking at the Patch 3/3, I see you reuse these definitions for functions as well. I just find the names confusing on the first look - "BTF_LINKAGE_STATIC". Naming aside, what do you think about adding the defines to include/btf.h instead ? > /* Mapping of CTF variables to the IDs they will be assigned when they are > converted to BTF_KIND_VAR type records. Strictly accounts for the index > from the start of the variable type entries, does not include the number > @@ -314,6 +318,9 @@ btf_collect_datasec (ctf_container_ref ctfc) > continue; > > const char *section_name = node->get_section (); > + /* Mark extern variables. */ > + if (DECL_EXTERNAL (node->decl)) > + dvd->dvd_visibility = BTF_LINKAGE_EXTERN; > This made me think about the following case. extern const char a[]; const char a[] = "foo"; What is the expected BTF for this? Since BTF can differentiate between the non-defining extern variable declaration, I expected to see two variables with different "linkage". At this time I see, two variables with global linkage but different types: .long 0xe000000 # btv_info .long 0x4 # btv_type .long 0x1 # btv_linkage .long 0x1f # btv_name .long 0xe000000 # btv_info .long 0x7 # btv_type .long 0x1 # btv_linkage .long 0x60 # btt_name > if (section_name == NULL) > { > @@ -676,7 +683,7 @@ btf_asm_varent (ctf_dvdef_ref var) > dw2_asm_output_data (4, var->dvd_name_offset, "btv_name"); > dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_VAR, 0, 0), "btv_info"); > dw2_asm_output_data (4, get_btf_id (var->dvd_type), "btv_type"); > - dw2_asm_output_data (4, (var->dvd_visibility ? 1 : 0), "btv_linkage"); > + dw2_asm_output_data (4, var->dvd_visibility, "btv_linkage"); > } > > /* Asm'out a member description following a BTF_KIND_STRUCT or > diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c b/gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c > new file mode 100644 > index 00000000000..d77600bae1c > --- /dev/null > +++ b/gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c > @@ -0,0 +1,24 @@ > +/* Test BTF generation for extern variables. */ > + > +/* { dg-do compile } */ > +/* { dg-options "-O0 -gbtf -dA" } */ > + > +/* Expect 4 variables. */ > +/* { dg-final { scan-assembler-times "\[\t \]0xe000000\[\t \]+\[^\n\]*btv_info" 4 } } */ > + > +/* 2 extern, 1 global, 1 static. */ > +/* { dg-final { scan-assembler-times "\[\t \]0\[\t \]+\[^\n\]*btv_linkage" 1 } } */ > +/* { dg-final { scan-assembler-times "\[\t \]0x1\[\t \]+\[^\n\]*btv_linkage" 1 } } */ > +/* { dg-final { scan-assembler-times "\[\t \]0x2\[\t \]+\[^\n\]*btv_linkage" 2 } } */ > + > +extern int a; > +extern const int b; > +int c; > +static const int d = 5; > + > +int foo (int x) > +{ > + c = a + b + x; > + > + return c + d; > +} > diff --git a/include/btf.h b/include/btf.h > index eba67f9d599..9a757ce5bc9 100644 > --- a/include/btf.h > +++ b/include/btf.h > @@ -182,7 +182,7 @@ struct btf_param > information about the variable. */ > struct btf_var > { > - uint32_t linkage; /* Currently only 0=static or 1=global. */ > + uint32_t linkage; /* 0=static, 1=global, 2=extern. */ > }; > > /* BTF_KIND_DATASEC is followed by VLEN struct btf_var_secinfo entries,
On 12/8/22 22:55, Indu Bhagat wrote: > Hi David, > > On 12/7/22 12:57, David Faust wrote: >> Add support for the 'extern' linkage value for BTF_KIND_VAR records, >> which is used for variables declared as extern in the source file. >> >> PR target/106773 >> >> gcc/ >> >> * btfout.cc (BTF_LINKAGE_STATIC): New define. >> (BTF_LINKAGE_GLOBAL): Likewise. >> (BTF_LINKAGE_EXTERN): Likewise. >> (btf_collect_datasec): Mark extern variables as such. >> (btf_asm_varent): Accomodate 'extern' linkage. >> >> gcc/testsuite/ >> >> * gcc.dg/debug/btf/btf-variables-4.c: New test. >> >> include/ >> >> * btf.h (struct btf_var): Update comment to note 'extern' linkage. >> --- >> gcc/btfout.cc | 9 ++++++- >> .../gcc.dg/debug/btf/btf-variables-4.c | 24 +++++++++++++++++++ >> include/btf.h | 2 +- >> 3 files changed, 33 insertions(+), 2 deletions(-) >> create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c >> >> diff --git a/gcc/btfout.cc b/gcc/btfout.cc >> index aef9fd70a28..a1c6266a7db 100644 >> --- a/gcc/btfout.cc >> +++ b/gcc/btfout.cc >> @@ -66,6 +66,10 @@ static char btf_info_section_label[MAX_BTF_LABEL_BYTES]; >> >> #define BTF_INVALID_TYPEID 0xFFFFFFFF >> >> +#define BTF_LINKAGE_STATIC 0 >> +#define BTF_LINKAGE_GLOBAL 1 >> +#define BTF_LINKAGE_EXTERN 2 >> + > > I was about to suggest to rename these to use the same name as used in > the kernel btf.h. What is used there is: > BTF_VAR_STATIC = 0, > BTF_VAR_GLOBAL_ALLOCATED = 1, > BTF_VAR_GLOBAL_EXTERN = 2, > > But after looking at the Patch 3/3, I see you reuse these definitions > for functions as well. I just find the names confusing on the first look > - "BTF_LINKAGE_STATIC". > > Naming aside, what do you think about adding the defines to > include/btf.h instead ? Actually, I forgot these are defined (separately for both VARs and FUNCs) in the kernel uapi/linux/btf.h. It would probably be best to mirror that approach and use a separate enum for each, in include/btf.h. WDYT? > >> /* Mapping of CTF variables to the IDs they will be assigned when they are >> converted to BTF_KIND_VAR type records. Strictly accounts for the index >> from the start of the variable type entries, does not include the number >> @@ -314,6 +318,9 @@ btf_collect_datasec (ctf_container_ref ctfc) >> continue; >> >> const char *section_name = node->get_section (); >> + /* Mark extern variables. */ >> + if (DECL_EXTERNAL (node->decl)) >> + dvd->dvd_visibility = BTF_LINKAGE_EXTERN; >> > > This made me think about the following case. > > extern const char a[]; > const char a[] = "foo"; > > What is the expected BTF for this? Since BTF can differentiate between > the non-defining extern variable declaration, I expected to see two > variables with different "linkage". At this time I see, two variables > with global linkage but different types: > > .long 0xe000000 # btv_info > .long 0x4 # btv_type > .long 0x1 # btv_linkage > .long 0x1f # btv_name > .long 0xe000000 # btv_info > .long 0x7 # btv_type > .long 0x1 # btv_linkage > .long 0x60 # btt_name > The BTF documentation in the kernel does not clarify this case. Going off the implementation in clang as a reference, it looks like only one VAR record is expected, with 'global' linkage: $ cat extdef.c extern const char a[]; const char a[] = "foo"; $ clang -target bpf -c -g extdef.c -o extdef.o $ /usr/sbin/bpftool btf dump file extdef.o [1] CONST '(anon)' type_id=2 [2] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED [3] ARRAY '(anon)' type_id=1 index_type_id=4 nr_elems=4 [4] INT '__ARRAY_SIZE_TYPE__' size=4 bits_offset=0 nr_bits=32 encoding=(none) [5] VAR 'a' type_id=3, linkage=global [6] DATASEC '.rodata' size=0 vlen=1 type_id=5 offset=0 size=4 (VAR 'a') In GCC we have two records since we have two DIEs for "a" in the DWARF. One has type "const char[4]" and the other has type "const char[]", so the BTF records point to two different types as well. I guess we should find a way in BTF to identify this and emit only the defining definition as clang does. >> if (section_name == NULL) >> { >> @@ -676,7 +683,7 @@ btf_asm_varent (ctf_dvdef_ref var) >> dw2_asm_output_data (4, var->dvd_name_offset, "btv_name"); >> dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_VAR, 0, 0), "btv_info"); >> dw2_asm_output_data (4, get_btf_id (var->dvd_type), "btv_type"); >> - dw2_asm_output_data (4, (var->dvd_visibility ? 1 : 0), "btv_linkage"); >> + dw2_asm_output_data (4, var->dvd_visibility, "btv_linkage"); >> } >> >> /* Asm'out a member description following a BTF_KIND_STRUCT or >> diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c b/gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c >> new file mode 100644 >> index 00000000000..d77600bae1c >> --- /dev/null >> +++ b/gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c >> @@ -0,0 +1,24 @@ >> +/* Test BTF generation for extern variables. */ >> + >> +/* { dg-do compile } */ >> +/* { dg-options "-O0 -gbtf -dA" } */ >> + >> +/* Expect 4 variables. */ >> +/* { dg-final { scan-assembler-times "\[\t \]0xe000000\[\t \]+\[^\n\]*btv_info" 4 } } */ >> + >> +/* 2 extern, 1 global, 1 static. */ >> +/* { dg-final { scan-assembler-times "\[\t \]0\[\t \]+\[^\n\]*btv_linkage" 1 } } */ >> +/* { dg-final { scan-assembler-times "\[\t \]0x1\[\t \]+\[^\n\]*btv_linkage" 1 } } */ >> +/* { dg-final { scan-assembler-times "\[\t \]0x2\[\t \]+\[^\n\]*btv_linkage" 2 } } */ >> + >> +extern int a; >> +extern const int b; >> +int c; >> +static const int d = 5; >> + >> +int foo (int x) >> +{ >> + c = a + b + x; >> + >> + return c + d; >> +} >> diff --git a/include/btf.h b/include/btf.h >> index eba67f9d599..9a757ce5bc9 100644 >> --- a/include/btf.h >> +++ b/include/btf.h >> @@ -182,7 +182,7 @@ struct btf_param >> information about the variable. */ >> struct btf_var >> { >> - uint32_t linkage; /* Currently only 0=static or 1=global. */ >> + uint32_t linkage; /* 0=static, 1=global, 2=extern. */ >> }; >> >> /* BTF_KIND_DATASEC is followed by VLEN struct btf_var_secinfo entries, >
On 12/12/22 12:47, David Faust wrote: > > > On 12/8/22 22:55, Indu Bhagat wrote: >> Hi David, >> >> On 12/7/22 12:57, David Faust wrote: >>> Add support for the 'extern' linkage value for BTF_KIND_VAR records, >>> which is used for variables declared as extern in the source file. >>> >>> PR target/106773 >>> >>> gcc/ >>> >>> * btfout.cc (BTF_LINKAGE_STATIC): New define. >>> (BTF_LINKAGE_GLOBAL): Likewise. >>> (BTF_LINKAGE_EXTERN): Likewise. >>> (btf_collect_datasec): Mark extern variables as such. >>> (btf_asm_varent): Accomodate 'extern' linkage. >>> >>> gcc/testsuite/ >>> >>> * gcc.dg/debug/btf/btf-variables-4.c: New test. >>> >>> include/ >>> >>> * btf.h (struct btf_var): Update comment to note 'extern' linkage. >>> --- >>> gcc/btfout.cc | 9 ++++++- >>> .../gcc.dg/debug/btf/btf-variables-4.c | 24 +++++++++++++++++++ >>> include/btf.h | 2 +- >>> 3 files changed, 33 insertions(+), 2 deletions(-) >>> create mode 100644 gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c >>> >>> diff --git a/gcc/btfout.cc b/gcc/btfout.cc >>> index aef9fd70a28..a1c6266a7db 100644 >>> --- a/gcc/btfout.cc >>> +++ b/gcc/btfout.cc >>> @@ -66,6 +66,10 @@ static char btf_info_section_label[MAX_BTF_LABEL_BYTES]; >>> >>> #define BTF_INVALID_TYPEID 0xFFFFFFFF >>> >>> +#define BTF_LINKAGE_STATIC 0 >>> +#define BTF_LINKAGE_GLOBAL 1 >>> +#define BTF_LINKAGE_EXTERN 2 >>> + >> >> I was about to suggest to rename these to use the same name as used in >> the kernel btf.h. What is used there is: >> BTF_VAR_STATIC = 0, >> BTF_VAR_GLOBAL_ALLOCATED = 1, >> BTF_VAR_GLOBAL_EXTERN = 2, >> >> But after looking at the Patch 3/3, I see you reuse these definitions >> for functions as well. I just find the names confusing on the first look >> - "BTF_LINKAGE_STATIC". >> >> Naming aside, what do you think about adding the defines to >> include/btf.h instead ? > > Actually, I forgot these are defined (separately for both VARs and FUNCs) > in the kernel uapi/linux/btf.h. It would probably be best to mirror that > approach and use a separate enum for each, in include/btf.h. WDYT? > Yes, mirroring in include/btf.h sounds good. >> >>> /* Mapping of CTF variables to the IDs they will be assigned when they are >>> converted to BTF_KIND_VAR type records. Strictly accounts for the index >>> from the start of the variable type entries, does not include the number >>> @@ -314,6 +318,9 @@ btf_collect_datasec (ctf_container_ref ctfc) >>> continue; >>> >>> const char *section_name = node->get_section (); >>> + /* Mark extern variables. */ >>> + if (DECL_EXTERNAL (node->decl)) >>> + dvd->dvd_visibility = BTF_LINKAGE_EXTERN; >>> >> >> This made me think about the following case. >> >> extern const char a[]; >> const char a[] = "foo"; >> >> What is the expected BTF for this? Since BTF can differentiate between >> the non-defining extern variable declaration, I expected to see two >> variables with different "linkage". At this time I see, two variables >> with global linkage but different types: >> >> .long 0xe000000 # btv_info >> .long 0x4 # btv_type >> .long 0x1 # btv_linkage >> .long 0x1f # btv_name >> .long 0xe000000 # btv_info >> .long 0x7 # btv_type >> .long 0x1 # btv_linkage >> .long 0x60 # btt_name >> > > The BTF documentation in the kernel does not clarify this case. > Going off the implementation in clang as a reference, it looks like > only one VAR record is expected, with 'global' linkage: > > $ cat extdef.c > extern const char a[]; > const char a[] = "foo"; > > $ clang -target bpf -c -g extdef.c -o extdef.o > > $ /usr/sbin/bpftool btf dump file extdef.o > [1] CONST '(anon)' type_id=2 > [2] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED > [3] ARRAY '(anon)' type_id=1 index_type_id=4 nr_elems=4 > [4] INT '__ARRAY_SIZE_TYPE__' size=4 bits_offset=0 nr_bits=32 encoding=(none) > [5] VAR 'a' type_id=3, linkage=global > [6] DATASEC '.rodata' size=0 vlen=1 > type_id=5 offset=0 size=4 (VAR 'a') > > In GCC we have two records since we have two DIEs for "a" in the > DWARF. One has type "const char[4]" and the other has type > "const char[]", so the BTF records point to two different types > as well. > > I guess we should find a way in BTF to identify this and > emit only the defining definition as clang does. > > CTF had a similar issue earlier. See PR105089. https://gcc.gnu.org/PR105089 >>> if (section_name == NULL) >>> { >>> @@ -676,7 +683,7 @@ btf_asm_varent (ctf_dvdef_ref var) >>> dw2_asm_output_data (4, var->dvd_name_offset, "btv_name"); >>> dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_VAR, 0, 0), "btv_info"); >>> dw2_asm_output_data (4, get_btf_id (var->dvd_type), "btv_type"); >>> - dw2_asm_output_data (4, (var->dvd_visibility ? 1 : 0), "btv_linkage"); >>> + dw2_asm_output_data (4, var->dvd_visibility, "btv_linkage"); >>> } >>> >>> /* Asm'out a member description following a BTF_KIND_STRUCT or >>> diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c b/gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c >>> new file mode 100644 >>> index 00000000000..d77600bae1c >>> --- /dev/null >>> +++ b/gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c >>> @@ -0,0 +1,24 @@ >>> +/* Test BTF generation for extern variables. */ >>> + >>> +/* { dg-do compile } */ >>> +/* { dg-options "-O0 -gbtf -dA" } */ >>> + >>> +/* Expect 4 variables. */ >>> +/* { dg-final { scan-assembler-times "\[\t \]0xe000000\[\t \]+\[^\n\]*btv_info" 4 } } */ >>> + >>> +/* 2 extern, 1 global, 1 static. */ >>> +/* { dg-final { scan-assembler-times "\[\t \]0\[\t \]+\[^\n\]*btv_linkage" 1 } } */ >>> +/* { dg-final { scan-assembler-times "\[\t \]0x1\[\t \]+\[^\n\]*btv_linkage" 1 } } */ >>> +/* { dg-final { scan-assembler-times "\[\t \]0x2\[\t \]+\[^\n\]*btv_linkage" 2 } } */ >>> + >>> +extern int a; >>> +extern const int b; >>> +int c; >>> +static const int d = 5; >>> + >>> +int foo (int x) >>> +{ >>> + c = a + b + x; >>> + >>> + return c + d; >>> +} >>> diff --git a/include/btf.h b/include/btf.h >>> index eba67f9d599..9a757ce5bc9 100644 >>> --- a/include/btf.h >>> +++ b/include/btf.h >>> @@ -182,7 +182,7 @@ struct btf_param >>> information about the variable. */ >>> struct btf_var >>> { >>> - uint32_t linkage; /* Currently only 0=static or 1=global. */ >>> + uint32_t linkage; /* 0=static, 1=global, 2=extern. */ >>> }; >>> >>> /* BTF_KIND_DATASEC is followed by VLEN struct btf_var_secinfo entries, >>
diff --git a/gcc/btfout.cc b/gcc/btfout.cc index aef9fd70a28..a1c6266a7db 100644 --- a/gcc/btfout.cc +++ b/gcc/btfout.cc @@ -66,6 +66,10 @@ static char btf_info_section_label[MAX_BTF_LABEL_BYTES]; #define BTF_INVALID_TYPEID 0xFFFFFFFF +#define BTF_LINKAGE_STATIC 0 +#define BTF_LINKAGE_GLOBAL 1 +#define BTF_LINKAGE_EXTERN 2 + /* Mapping of CTF variables to the IDs they will be assigned when they are converted to BTF_KIND_VAR type records. Strictly accounts for the index from the start of the variable type entries, does not include the number @@ -314,6 +318,9 @@ btf_collect_datasec (ctf_container_ref ctfc) continue; const char *section_name = node->get_section (); + /* Mark extern variables. */ + if (DECL_EXTERNAL (node->decl)) + dvd->dvd_visibility = BTF_LINKAGE_EXTERN; if (section_name == NULL) { @@ -676,7 +683,7 @@ btf_asm_varent (ctf_dvdef_ref var) dw2_asm_output_data (4, var->dvd_name_offset, "btv_name"); dw2_asm_output_data (4, BTF_TYPE_INFO (BTF_KIND_VAR, 0, 0), "btv_info"); dw2_asm_output_data (4, get_btf_id (var->dvd_type), "btv_type"); - dw2_asm_output_data (4, (var->dvd_visibility ? 1 : 0), "btv_linkage"); + dw2_asm_output_data (4, var->dvd_visibility, "btv_linkage"); } /* Asm'out a member description following a BTF_KIND_STRUCT or diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c b/gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c new file mode 100644 index 00000000000..d77600bae1c --- /dev/null +++ b/gcc/testsuite/gcc.dg/debug/btf/btf-variables-4.c @@ -0,0 +1,24 @@ +/* Test BTF generation for extern variables. */ + +/* { dg-do compile } */ +/* { dg-options "-O0 -gbtf -dA" } */ + +/* Expect 4 variables. */ +/* { dg-final { scan-assembler-times "\[\t \]0xe000000\[\t \]+\[^\n\]*btv_info" 4 } } */ + +/* 2 extern, 1 global, 1 static. */ +/* { dg-final { scan-assembler-times "\[\t \]0\[\t \]+\[^\n\]*btv_linkage" 1 } } */ +/* { dg-final { scan-assembler-times "\[\t \]0x1\[\t \]+\[^\n\]*btv_linkage" 1 } } */ +/* { dg-final { scan-assembler-times "\[\t \]0x2\[\t \]+\[^\n\]*btv_linkage" 2 } } */ + +extern int a; +extern const int b; +int c; +static const int d = 5; + +int foo (int x) +{ + c = a + b + x; + + return c + d; +} diff --git a/include/btf.h b/include/btf.h index eba67f9d599..9a757ce5bc9 100644 --- a/include/btf.h +++ b/include/btf.h @@ -182,7 +182,7 @@ struct btf_param information about the variable. */ struct btf_var { - uint32_t linkage; /* Currently only 0=static or 1=global. */ + uint32_t linkage; /* 0=static, 1=global, 2=extern. */ }; /* BTF_KIND_DATASEC is followed by VLEN struct btf_var_secinfo entries,