Message ID | 877d458k7r.fsf@oracle.com |
---|---|
State | New, archived |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f503:0:0:0:0:0 with SMTP id q3csp189944wro; Fri, 22 Jul 2022 04:24:34 -0700 (PDT) X-Google-Smtp-Source: AGRyM1u7FFdE90AU2DS94ToPAv6fdBkaXCvYWoT8BUzwY6SANpPO++AzhsqoyQyFr6vyKbmomBjB X-Received: by 2002:a05:6402:388d:b0:43b:a17b:6212 with SMTP id fd13-20020a056402388d00b0043ba17b6212mr103595edb.51.1658489074752; Fri, 22 Jul 2022 04:24:34 -0700 (PDT) Received: from sourceware.org (ip-8-43-85-97.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id h18-20020a05640250d200b004357feb6876si6293492edb.36.2022.07.22.04.24.34 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Jul 2022 04:24:34 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b="A/yxA3Aq"; arc=fail (signature failed); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6214C3834E48 for <ouuuleilei@gmail.com>; Fri, 22 Jul 2022 11:24:18 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6214C3834E48 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1658489058; bh=LeQXq8ZwCQ8Fua8uIKjoUdonrtOIup1E8F7CMH7CBtQ=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=A/yxA3AqqrVspCK58AAK1VULFMuf0tkGdQYw3qU9sTvAABmon4CUtyjcHy0nEO6MK 1ZL44kmQuMJw2dK+z8+U+79czdrp8KUeV/5htK/pL08twM/TG+AsBzTi2hatnNOQyy YDUcGWBGGXrS6ATFjN4qhPZ4TcFSvsaUzVa8WIb0= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by sourceware.org (Postfix) with ESMTPS id 0102C38356A7 for <gcc-patches@gcc.gnu.org>; Fri, 22 Jul 2022 11:23:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0102C38356A7 Received: from pps.filterd (m0246631.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 26MB9ADi006327 for <gcc-patches@gcc.gnu.org>; Fri, 22 Jul 2022 11:23:31 GMT Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3hbm42q6u3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <gcc-patches@gcc.gnu.org>; Fri, 22 Jul 2022 11:23:30 +0000 Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.5/8.17.1.5) with ESMTP id 26M9Eo6p007888 for <gcc-patches@gcc.gnu.org>; Fri, 22 Jul 2022 11:23:30 GMT Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2104.outbound.protection.outlook.com [104.47.70.104]) by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3hc1k6dbyq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <gcc-patches@gcc.gnu.org>; Fri, 22 Jul 2022 11:23:30 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=blhEnQsr9GBNZecObZMQASXv51TcNcdOwEoOZALsgNCAodRw7H5VMdQHuVnrd6Bp+uE9/XuEysFTvCeb+avR9ouEzXASne/N8swwqVmT3IaoqjgryQu2HQCjrqTegGK+MbwCevZCwGtbc+uNiybNSzO8EJqhYEI3mts8Qqd/kr/yc6kO+A/lSE12Y3cfWsiQZzO5+ihrfXPqtfR6AnvrNIqnBseV/x18I8Spb6vvyJg+3SyNSTAYbbeSHhv2GwSIgyIGlvg882cud57EJ00mk2qDltDHy8xGWfts+GdQ7IEJSOWCul+FX7EiFPslCzDt8yiGt7ADTwkHQGHuxOSGnA== 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=LeQXq8ZwCQ8Fua8uIKjoUdonrtOIup1E8F7CMH7CBtQ=; b=AIOQpZKfor/K6z9Oa8oF9Vei9mVUaQZHJLAVmYqDZgQWP3yPx5gd5gTjzKsQTzuhKeHy+3yj041z8y0GP4MDUOcvQitk3KDM1p7DS5tfZDCbVEwtwX9EGOyphuL7T/QnOKAZB7JdAXiYfhLcmgRduK9DqYhF5JKWJ359YSFytzMIRKX51kXkjcPH2yQr6q6p2PmXFTaCiDXC4DKppm8Qdvp3VOZvIqpqNT6X/qlrlF/8N3XP4EPb3jXpsMeWuCKso6bfCv3CIuBUOcqrKpxvZWPX4b/8/9ApJSqFdFn+a8MDrEAZ7tQ4UOoKgmm7uJHloetO9ffGm5K4PlKQyhUu1A== 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 BYAPR10MB2888.namprd10.prod.outlook.com (2603:10b6:a03:88::32) by SA1PR10MB5866.namprd10.prod.outlook.com (2603:10b6:806:22b::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5458.19; Fri, 22 Jul 2022 11:23:28 +0000 Received: from BYAPR10MB2888.namprd10.prod.outlook.com ([fe80::b5ee:262a:b151:2fdd]) by BYAPR10MB2888.namprd10.prod.outlook.com ([fe80::b5ee:262a:b151:2fdd%4]) with mapi id 15.20.5438.024; Fri, 22 Jul 2022 11:23:28 +0000 To: gcc-patches@gcc.gnu.org Subject: [PATCH] btf: do not use the CHAR `encoding' bit for BTF Date: Fri, 22 Jul 2022 13:23:20 +0200 Message-ID: <877d458k7r.fsf@oracle.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Content-Type: text/plain X-ClientProxiedBy: AS9P251CA0003.EURP251.PROD.OUTLOOK.COM (2603:10a6:20b:50f::7) To BYAPR10MB2888.namprd10.prod.outlook.com (2603:10b6:a03:88::32) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 63efdd64-1043-4541-6b5b-08da6bd499c2 X-MS-TrafficTypeDiagnostic: SA1PR10MB5866:EE_ X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: cO0L86WZMMXmPHcz4yI9Ak86snhtMY2gEEQ0cl9uzZjIDhG9GS+r8kDMFz7J+AiguO+lQfXgP2bFw5XVLMoylzLmFjAiLgPF6romfP2lhZXm4i2HeyHix8t+1BzqcuFzSjUk0EwdHKgvmaNx6xZ+D9DrefJPDvCQdTO9/bPapxEyd1xlgG6f6s+//MYHWEXRxhEDOdxeTFCqhe/nFA8GYuUadIlcxCmvNWxb8kX2gIfw48fH0vQpoO4mYwiZouP4/mUDYqcfRmo12YtYruMJRm2zLNwj59rfjUy0qwMNziVnJyWzsSFBkQTmakHwSRM6maki0Hn23L1nHRD7U8QmGMAFXLYMchzBCjnwzr8iFyxN+IeDoTDquVLBhcPX9YlzHd+aTiP2ZjwbysPyzzIcDwZfmPcnTRx6Vfopl4aRurbU0KKnkSZOCGYLV9Q9DPpDe095wA85HfYM+VjAwvcpcZZ2SM3VEIH29CcU9h52U3S9CjR39+SPSXDVlgAohl+Cd0yjkbokUc62y3vHeo9oxyEmfDW+JNZb+wQu32LT+0ECh1EPqxoyhd+rHv1sAW72Nij779Dijz/y5kPhwOp64y7DJaPkB83SpNNGdVnnV9JlYEZfo9A4jbex51cVpHLLyeYi5rP2lXlNtNow1SqsWZvx2vDcWd5+ysVi2j2ap+7Ig3Km9IlfOaJS+5P5vRD9QTANP81NnU8feZi038/6LA5oReIdHeXQap6ehQb5zwMtbvVXV909282zudfXZihcY7INPvpJi74DC02pJqEYqAm8K5/UIZ2LmAdOk5g4VD3M5U8f/fyhpq815C2UUTx4qYrUc4HjImViW9scKtbPZg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR10MB2888.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(136003)(366004)(39860400002)(376002)(346002)(396003)(36756003)(86362001)(5660300002)(8936002)(6666004)(83380400001)(107886003)(26005)(2616005)(6506007)(52116002)(186003)(38350700002)(38100700002)(6512007)(84970400001)(6916009)(316002)(41300700001)(66946007)(66476007)(66556008)(966005)(8676002)(4326008)(2906002)(6486002)(478600001)(81973001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: 0h7Uv2svRuYq33kpEsjTVf+Zj8Hjm6HceYcZZy4NXYqldGlLdg1e2eiTGtTe4ueFkjBQm1Qb1rxtbTL1bcs1DI2Swpfen008ApiyBl+TKzW84crkpBrz1+GP+VA7oYAdgkt5mTJvzk/YEgiu2P1+MHDexyfPXJzK5jtOc7z0D7eEBKoFw3Wq11mC8Pxp+5fO7nBZb7FZuNwKpIEvkW3wxMjXJih+UuQ+ErUOArTTn43O+UACSTF1td44Tl3Hp+5Lkl5xCVLrflPd5Uwk23ieNb631HptrPXqpPqEIMX/k7iRyI8k8QSK+YATCgoH/y3/of/aJy63X6HojqC7rKCVBf9UAnWyn20ipSG1WRNrhDBti/lGHzlnnH/B3GI8aQluml4cCAhY8xncs9XfJq3rZYtyvfSEHM2BFTYqGj+lcXFQ45IZQKZ+uTrbwTw0QksIhyYlaCO4DGFTmwyHjJARzSkj0HgURPCTiKsnl8+CD1awfpiG1viNH167UYy6F92ugu9anqyG56w6SXgImLQ6TzW/OSVmcpu2QLTv0aTTKjakLkWI5zfLj/2FQXQrPig90PdQJtSNrEgxq8eRcHnx+ei0KdQQ9EduUJ6UpbHT515xlnviz9VIM79cvSebOeTyG4FhwOe+yUhtSYMfON9ErqVaSZ3dd721OadfNx4dACAOiua/T4oWchqaCq3aYFW/sNeNAMKwvwOa+lB3m843XjsqKHRtF582ouBoMynE7pj4DkKoAB/ygg5nrxik51k+waW15m+z2xTWjF/dyoWzevi7XM/8Gu7MrboUVKj/SL46aHHiwqouIMPPY3YV2Y8P+iTVZHJ6XVrbRYGip8XMjB2026bbE4i4X299lSNDQiL9WDUp957S/U0IE+5Abj6u/fL3l6ZReVPxbYzYKtoN51+Tk4JdQQgrQw50J0a/u4Q4k2uUq97EVckipRC0eGzHcFUTzd8ZvNkgZywgtNHxtU2J3qkTiXLjeVAhtyXqBs9aEVw/5BPEVA/5pH26FVPLN3rxZKfypnu3fRicT07jagbYBBgoQgByo9PkP6grjZZvnmu42fxuuh09hSm+4/MAk0v2iWG4uQ/Ft3nO2UGJ6Ekc3d5kssKlXUPBXG8GbTSuW5l3XWNc23LW8W/fmwzgu5fWf08xvpmCZXdewJRj+bSdXJQS/j9JbkIb24nmRgX1VN/q1G7o/pHyW9iRzj1ZUmR0qve7GPC4fJay2OjEnaQghZQdmDGNrzNVNdyY0FX6V+K/zsxyBAVUCBFiI7oyvix0GkCJ9Cc1Bh6+LnuDUCZHPyxY4TGzkwDAJcsLs5Ga+ryKL4xAgLlf7beEhY6223LQ35U+OhXcJKKxuzaNzHx4Q+XgLltGd7VBT1CRsnI5xkJ9TLl9yO5DoN3fQDBps1BtgQUFeGNKbfkyLLyHzVuYRAbYvf+tVgjjiwKUgtmDQ/WGzR3PEXasFqNxl7Xd3+FU40sGTEuB7D71Bj+vnCLzg073P9SMdXBXq7wkSsHzWHzrtYBmFMQfKRRe42Hg0yo5L5mKF61XnDGDOyqLYCCsRDwvdyfehrjbMBoxoL3F/mWxQTp5Du++ZXqL8E8HLvdL3VgXSP3w6tQbjLqiRA== X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 63efdd64-1043-4541-6b5b-08da6bd499c2 X-MS-Exchange-CrossTenant-AuthSource: BYAPR10MB2888.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jul 2022 11:23:28.4646 (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: u9CzFbCcX87l2d3j1qfGZX37/iLdzGsw1/HWMhYsvirVA4XdqS4Ki2M9hGejPqChRfoD+qhM3Fiva7bEzQ8B07q5/14kzLVwT+BhPsG5O7c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR10MB5866 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-07-22_02,2022-07-21_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 adultscore=0 phishscore=0 mlxlogscore=927 spamscore=0 malwarescore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207220048 X-Proofpoint-ORIG-GUID: IZ8UqVXpb6ornm7whOIGP0VYgjAome7U X-Proofpoint-GUID: IZ8UqVXpb6ornm7whOIGP0VYgjAome7U X-Spam-Status: No, score=-11.9 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: "Jose E. Marchesi via Gcc-patches" <gcc-patches@gcc.gnu.org> Reply-To: "Jose E. Marchesi" <jose.marchesi@oracle.com> Cc: indu.bhagat@oracle.com Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1739051840188234606?= X-GMAIL-MSGID: =?utf-8?q?1739051840188234606?= |
Series |
btf: do not use the CHAR `encoding' bit for BTF
|
|
Commit Message
Li, Pan2 via Gcc-patches
July 22, 2022, 11:23 a.m. UTC
Contrary to CTF and our previous expectations, as per [1], turns out that in BTF: 1) The `encoding' field in integer types shall not be treated as a bitmap, but as an enumerated, i.e. these bits are exclusive to each other. 2) The CHAR bit in `encoding' shall _not_ be set when emitting types for char nor `unsigned char'. Consequently this patch clears the CHAR bit before emitting the variable part of BTF integral types. It also updates the testsuite accordingly, expanding it to check for BOOL bits. [1] https://lore.kernel.org/bpf/a73586ad-f2dc-0401-1eba-2004357b7edf@fb.com/T/#t gcc/ChangeLog: * btfout.cc (output_asm_btf_vlen_bytes): Do not use the CHAR encoding bit in BTF. gcc/testsuite/ChangeLog: * gcc.dg/debug/btf/btf-int-1.c: Do not check for char bits in bti_encoding and check for bool bits. --- gcc/btfout.cc | 4 ++++ gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c | 18 +++++++++++------- 2 files changed, 15 insertions(+), 7 deletions(-)
Comments
On 7/22/22 4:23 AM, Jose E. Marchesi via Gcc-patches wrote: > > Contrary to CTF and our previous expectations, as per [1], turns out > that in BTF: > > 1) The `encoding' field in integer types shall not be treated as a > bitmap, but as an enumerated, i.e. these bits are exclusive to each > other. > > 2) The CHAR bit in `encoding' shall _not_ be set when emitting types > for char nor `unsigned char'. > Hmm...well. At this time, I suggest we make a note of this in the btf.h for posterity that BTF_INT_CHAR is to not be used (i.e., BTF_INT_CHAR should not be set for char / unsigned char). > Consequently this patch clears the CHAR bit before emitting the > variable part of BTF integral types. It also updates the testsuite > accordingly, expanding it to check for BOOL bits. > > [1] https://lore.kernel.org/bpf/a73586ad-f2dc-0401-1eba-2004357b7edf@fb.com/T/#t > > gcc/ChangeLog: > > * btfout.cc (output_asm_btf_vlen_bytes): Do not use the CHAR > encoding bit in BTF. > > gcc/testsuite/ChangeLog: > > * gcc.dg/debug/btf/btf-int-1.c: Do not check for char bits in > bti_encoding and check for bool bits. > --- > gcc/btfout.cc | 4 ++++ > gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c | 18 +++++++++++------- > 2 files changed, 15 insertions(+), 7 deletions(-) > > diff --git a/gcc/btfout.cc b/gcc/btfout.cc > index 31af50521da..576f73d47cf 100644 > --- a/gcc/btfout.cc > +++ b/gcc/btfout.cc > @@ -914,6 +914,10 @@ output_asm_btf_vlen_bytes (ctf_container_ref ctfc, ctf_dtdef_ref dtd) > if (dtd->dtd_data.ctti_size < 1) > break; > > + /* In BTF the CHAR `encoding' seems to not be used, so clear it > + here. */ > + dtd->dtd_u.dtu_enc.cte_format &= ~BTF_INT_CHAR; > + [Added David Faust] What do you think about doing this in btf_dtd_emit_preprocess_cb () for types where kind == BTF_KIND_INT. This is the place where BTF specific massaging of type info takes place. > encoding = BTF_INT_DATA (dtd->dtd_u.dtu_enc.cte_format, > dtd->dtd_u.dtu_enc.cte_offset, > dtd->dtd_u.dtu_enc.cte_bits); > diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c b/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c > index 2381decd6ff..87d9758e9cb 100644 > --- a/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c > +++ b/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c > @@ -4,7 +4,8 @@ > | 0 | encoding | offset | 00 | bits | > encoding: > signed 1 << 24 > - char 2 << 24 > + char 2 << 24 (not used) > + bool 4 << 24 > > All offsets in this test should be 0. > This test does _not_ check number of bits, as it may vary between targets. > @@ -13,13 +14,14 @@ > /* { dg-do compile } */ > /* { dg-options "-O0 -gbtf -dA" } */ > > -/* Check for 8 BTF_KIND_INT types. */ > -/* { dg-final { scan-assembler-times "\[\t \]0x1000000\[\t \]+\[^\n\]*btt_info" 8 } } */ > +/* Check for 9 BTF_KIND_INT types. */ > +/* { dg-final { scan-assembler-times "\[\t \]0x1000000\[\t \]+\[^\n\]*btt_info" 9 } } */ > > -/* Check the signed/char flags, but not bit size. */ > -/* { dg-final { scan-assembler-times "\[\t \]0x10000..\[\t \]+\[^\n\]*bti_encoding" 3 } } */ > -/* { dg-final { scan-assembler-times "\[\t \]0x20000..\[\t \]+\[^\n\]*bti_encoding" 1 } } */ > -/* { dg-final { scan-assembler-times "\[\t \]0x30000..\[\t \]+\[^\n\]*bti_encoding" 1 } } */ > +/* Check the signed flags, but not bit size. */ > +/* { dg-final { scan-assembler-times "\[\t \]0x10000..\[\t \]+\[^\n\]*bti_encoding" 4 } } */ > +/* { dg-final { scan-assembler-times "\[\t \]0x..\[\t \]+\[^\n\]*bti_encoding" 3 } } */ > +/* { dg-final { scan-assembler-times "\[\t \]0x.\[\t \]+\[^\n\]*bti_encoding" 1 } } */ > +/* { dg-final { scan-assembler-times "\[\t \]0x40000..\[\t \]+\[^\n\]*bti_encoding" 1 } } */ > > /* Check that there is a string entry for each type name. */ > /* { dg-final { scan-assembler-times "ascii \"unsigned char.0\"\[\t \]+\[^\n\]*btf_string" 1 } } */ > @@ -42,3 +44,5 @@ signed int f = -66; > > unsigned long int g = 77; > signed long int h = 88; > + > +_Bool x = 1; >
On 7/26/22 14:58, Indu Bhagat wrote: > On 7/22/22 4:23 AM, Jose E. Marchesi via Gcc-patches wrote: >> >> Contrary to CTF and our previous expectations, as per [1], turns out >> that in BTF: >> >> 1) The `encoding' field in integer types shall not be treated as a >> bitmap, but as an enumerated, i.e. these bits are exclusive to each >> other. >> >> 2) The CHAR bit in `encoding' shall _not_ be set when emitting types >> for char nor `unsigned char'. >> > > Hmm...well. At this time, I suggest we make a note of this in the btf.h > for posterity that BTF_INT_CHAR is to not be used (i.e., BTF_INT_CHAR > should not be set for char / unsigned char). Agreed it would be good to add this note. > >> Consequently this patch clears the CHAR bit before emitting the >> variable part of BTF integral types. It also updates the testsuite >> accordingly, expanding it to check for BOOL bits. >> >> [1] https://lore.kernel.org/bpf/a73586ad-f2dc-0401-1eba-2004357b7edf@fb.com/T/#t >> >> gcc/ChangeLog: >> >> * btfout.cc (output_asm_btf_vlen_bytes): Do not use the CHAR >> encoding bit in BTF. >> >> gcc/testsuite/ChangeLog: >> >> * gcc.dg/debug/btf/btf-int-1.c: Do not check for char bits in >> bti_encoding and check for bool bits. >> --- >> gcc/btfout.cc | 4 ++++ >> gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c | 18 +++++++++++------- >> 2 files changed, 15 insertions(+), 7 deletions(-) >> >> diff --git a/gcc/btfout.cc b/gcc/btfout.cc >> index 31af50521da..576f73d47cf 100644 >> --- a/gcc/btfout.cc >> +++ b/gcc/btfout.cc >> @@ -914,6 +914,10 @@ output_asm_btf_vlen_bytes (ctf_container_ref ctfc, ctf_dtdef_ref dtd) >> if (dtd->dtd_data.ctti_size < 1) >> break; >> >> + /* In BTF the CHAR `encoding' seems to not be used, so clear it >> + here. */ >> + dtd->dtd_u.dtu_enc.cte_format &= ~BTF_INT_CHAR; >> + > > [Added David Faust] > > What do you think about doing this in btf_dtd_emit_preprocess_cb () for > types where kind == BTF_KIND_INT. This is the place where BTF specific > massaging of type info takes place. Sorry for the delay. I think this could be done in either place. I lean slightly in favor of doing it here as implemented in this patch. Other integer encodings are not specifically massaged into BTF; we leave the in-memory representation the same as CTF and just write them out according to the BTF rules since both formats hold the same information, and this function is where we do that. In my opinion, this is a similar case. It is not wrong hold on to the information (internally) that this is a char type, rather it is a quirk of the other BTF encoding rules which means it _is_ wrong to ever set the bit saying as much when writing the BTF info (at least for now...). So, this patch LGTM, but please add a brief note in btf.h that the CHAR flag is currently not to be used. Thanks > >> encoding = BTF_INT_DATA (dtd->dtd_u.dtu_enc.cte_format, >> dtd->dtd_u.dtu_enc.cte_offset, >> dtd->dtd_u.dtu_enc.cte_bits); >> diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c b/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c >> index 2381decd6ff..87d9758e9cb 100644 >> --- a/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c >> +++ b/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c >> @@ -4,7 +4,8 @@ >> | 0 | encoding | offset | 00 | bits | >> encoding: >> signed 1 << 24 >> - char 2 << 24 >> + char 2 << 24 (not used) >> + bool 4 << 24 >> >> All offsets in this test should be 0. >> This test does _not_ check number of bits, as it may vary between targets. >> @@ -13,13 +14,14 @@ >> /* { dg-do compile } */ >> /* { dg-options "-O0 -gbtf -dA" } */ >> >> -/* Check for 8 BTF_KIND_INT types. */ >> -/* { dg-final { scan-assembler-times "\[\t \]0x1000000\[\t \]+\[^\n\]*btt_info" 8 } } */ >> +/* Check for 9 BTF_KIND_INT types. */ >> +/* { dg-final { scan-assembler-times "\[\t \]0x1000000\[\t \]+\[^\n\]*btt_info" 9 } } */ >> >> -/* Check the signed/char flags, but not bit size. */ >> -/* { dg-final { scan-assembler-times "\[\t \]0x10000..\[\t \]+\[^\n\]*bti_encoding" 3 } } */ >> -/* { dg-final { scan-assembler-times "\[\t \]0x20000..\[\t \]+\[^\n\]*bti_encoding" 1 } } */ >> -/* { dg-final { scan-assembler-times "\[\t \]0x30000..\[\t \]+\[^\n\]*bti_encoding" 1 } } */ >> +/* Check the signed flags, but not bit size. */ >> +/* { dg-final { scan-assembler-times "\[\t \]0x10000..\[\t \]+\[^\n\]*bti_encoding" 4 } } */ >> +/* { dg-final { scan-assembler-times "\[\t \]0x..\[\t \]+\[^\n\]*bti_encoding" 3 } } */ >> +/* { dg-final { scan-assembler-times "\[\t \]0x.\[\t \]+\[^\n\]*bti_encoding" 1 } } */ >> +/* { dg-final { scan-assembler-times "\[\t \]0x40000..\[\t \]+\[^\n\]*bti_encoding" 1 } } */ >> >> /* Check that there is a string entry for each type name. */ >> /* { dg-final { scan-assembler-times "ascii \"unsigned char.0\"\[\t \]+\[^\n\]*btf_string" 1 } } */ >> @@ -42,3 +44,5 @@ signed int f = -66; >> >> unsigned long int g = 77; >> signed long int h = 88; >> + >> +_Bool x = 1; >> >
> On 7/26/22 14:58, Indu Bhagat wrote: >> On 7/22/22 4:23 AM, Jose E. Marchesi via Gcc-patches wrote: >>> >>> Contrary to CTF and our previous expectations, as per [1], turns out >>> that in BTF: >>> >>> 1) The `encoding' field in integer types shall not be treated as a >>> bitmap, but as an enumerated, i.e. these bits are exclusive to each >>> other. >>> >>> 2) The CHAR bit in `encoding' shall _not_ be set when emitting types >>> for char nor `unsigned char'. >>> >> >> Hmm...well. At this time, I suggest we make a note of this in the btf.h >> for posterity that BTF_INT_CHAR is to not be used (i.e., BTF_INT_CHAR >> should not be set for char / unsigned char). > > Agreed it would be good to add this note. Hmm, I am not sure such a comment actually belongs to include/btf.h, which is not specific to the compiler and is supposed to reflect the BTF format per-se. The CHAR bit is documented in the kernel documentation and it may be used at some point by bpflib, or who knows what. That's why I put the comment in btfout.cc instead, to make it clear that BTF_INT_CHAR is indeed not to be set for char / unsigned char by the compiler: >>> + /* In BTF the CHAR `encoding' seems to not be used, so clear it >>> + here. */ >>> + dtd->dtd_u.dtu_enc.cte_format &= ~BTF_INT_CHAR;
On 8/2/22 08:42, Jose E. Marchesi wrote: > >> On 7/26/22 14:58, Indu Bhagat wrote: >>> On 7/22/22 4:23 AM, Jose E. Marchesi via Gcc-patches wrote: >>>> >>>> Contrary to CTF and our previous expectations, as per [1], turns out >>>> that in BTF: >>>> >>>> 1) The `encoding' field in integer types shall not be treated as a >>>> bitmap, but as an enumerated, i.e. these bits are exclusive to each >>>> other. >>>> >>>> 2) The CHAR bit in `encoding' shall _not_ be set when emitting types >>>> for char nor `unsigned char'. >>>> >>> >>> Hmm...well. At this time, I suggest we make a note of this in the btf.h >>> for posterity that BTF_INT_CHAR is to not be used (i.e., BTF_INT_CHAR >>> should not be set for char / unsigned char). >> >> Agreed it would be good to add this note. > > Hmm, I am not sure such a comment actually belongs to include/btf.h, > which is not specific to the compiler and is supposed to reflect the BTF > format per-se. The CHAR bit is documented in the kernel documentation > and it may be used at some point by bpflib, or who knows what. OK you make a good point. In that case the patch LGTM to commit. Thanks! > > That's why I put the comment in btfout.cc instead, to make it clear that > BTF_INT_CHAR is indeed not to be set for char / unsigned char by the > compiler: > >>>> + /* In BTF the CHAR `encoding' seems to not be used, so clear it >>>> + here. */ >>>> + dtd->dtd_u.dtu_enc.cte_format &= ~BTF_INT_CHAR;
> On 8/2/22 08:42, Jose E. Marchesi wrote: >> >>> On 7/26/22 14:58, Indu Bhagat wrote: >>>> On 7/22/22 4:23 AM, Jose E. Marchesi via Gcc-patches wrote: >>>>> >>>>> Contrary to CTF and our previous expectations, as per [1], turns out >>>>> that in BTF: >>>>> >>>>> 1) The `encoding' field in integer types shall not be treated as a >>>>> bitmap, but as an enumerated, i.e. these bits are exclusive to each >>>>> other. >>>>> >>>>> 2) The CHAR bit in `encoding' shall _not_ be set when emitting types >>>>> for char nor `unsigned char'. >>>>> >>>> >>>> Hmm...well. At this time, I suggest we make a note of this in the btf.h >>>> for posterity that BTF_INT_CHAR is to not be used (i.e., BTF_INT_CHAR >>>> should not be set for char / unsigned char). >>> >>> Agreed it would be good to add this note. >> >> Hmm, I am not sure such a comment actually belongs to include/btf.h, >> which is not specific to the compiler and is supposed to reflect the BTF >> format per-se. The CHAR bit is documented in the kernel documentation >> and it may be used at some point by bpflib, or who knows what. > > OK you make a good point. > > In that case the patch LGTM to commit. Thanks! Pushed to master. Thanks! >> >> That's why I put the comment in btfout.cc instead, to make it clear that >> BTF_INT_CHAR is indeed not to be set for char / unsigned char by the >> compiler: >> >>>>> + /* In BTF the CHAR `encoding' seems to not be used, so clear it >>>>> + here. */ >>>>> + dtd->dtd_u.dtu_enc.cte_format &= ~BTF_INT_CHAR;
diff --git a/gcc/btfout.cc b/gcc/btfout.cc index 31af50521da..576f73d47cf 100644 --- a/gcc/btfout.cc +++ b/gcc/btfout.cc @@ -914,6 +914,10 @@ output_asm_btf_vlen_bytes (ctf_container_ref ctfc, ctf_dtdef_ref dtd) if (dtd->dtd_data.ctti_size < 1) break; + /* In BTF the CHAR `encoding' seems to not be used, so clear it + here. */ + dtd->dtd_u.dtu_enc.cte_format &= ~BTF_INT_CHAR; + encoding = BTF_INT_DATA (dtd->dtd_u.dtu_enc.cte_format, dtd->dtd_u.dtu_enc.cte_offset, dtd->dtd_u.dtu_enc.cte_bits); diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c b/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c index 2381decd6ff..87d9758e9cb 100644 --- a/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c +++ b/gcc/testsuite/gcc.dg/debug/btf/btf-int-1.c @@ -4,7 +4,8 @@ | 0 | encoding | offset | 00 | bits | encoding: signed 1 << 24 - char 2 << 24 + char 2 << 24 (not used) + bool 4 << 24 All offsets in this test should be 0. This test does _not_ check number of bits, as it may vary between targets. @@ -13,13 +14,14 @@ /* { dg-do compile } */ /* { dg-options "-O0 -gbtf -dA" } */ -/* Check for 8 BTF_KIND_INT types. */ -/* { dg-final { scan-assembler-times "\[\t \]0x1000000\[\t \]+\[^\n\]*btt_info" 8 } } */ +/* Check for 9 BTF_KIND_INT types. */ +/* { dg-final { scan-assembler-times "\[\t \]0x1000000\[\t \]+\[^\n\]*btt_info" 9 } } */ -/* Check the signed/char flags, but not bit size. */ -/* { dg-final { scan-assembler-times "\[\t \]0x10000..\[\t \]+\[^\n\]*bti_encoding" 3 } } */ -/* { dg-final { scan-assembler-times "\[\t \]0x20000..\[\t \]+\[^\n\]*bti_encoding" 1 } } */ -/* { dg-final { scan-assembler-times "\[\t \]0x30000..\[\t \]+\[^\n\]*bti_encoding" 1 } } */ +/* Check the signed flags, but not bit size. */ +/* { dg-final { scan-assembler-times "\[\t \]0x10000..\[\t \]+\[^\n\]*bti_encoding" 4 } } */ +/* { dg-final { scan-assembler-times "\[\t \]0x..\[\t \]+\[^\n\]*bti_encoding" 3 } } */ +/* { dg-final { scan-assembler-times "\[\t \]0x.\[\t \]+\[^\n\]*bti_encoding" 1 } } */ +/* { dg-final { scan-assembler-times "\[\t \]0x40000..\[\t \]+\[^\n\]*bti_encoding" 1 } } */ /* Check that there is a string entry for each type name. */ /* { dg-final { scan-assembler-times "ascii \"unsigned char.0\"\[\t \]+\[^\n\]*btf_string" 1 } } */ @@ -42,3 +44,5 @@ signed int f = -66; unsigned long int g = 77; signed long int h = 88; + +_Bool x = 1;