From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by sourceware.org (Postfix) with ESMTPS id 911B83857806 for ; Wed, 16 Mar 2022 09:37:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 911B83857806 X-IronPort-AV: E=McAfee;i="6200,9189,10286"; a="342965906" X-IronPort-AV: E=Sophos;i="5.90,186,1643702400"; d="scan'208";a="342965906" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Mar 2022 02:37:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.90,186,1643702400"; d="scan'208";a="580843819" Received: from fmsmsx604.amr.corp.intel.com ([10.18.126.84]) by orsmga001.jf.intel.com with ESMTP; 16 Mar 2022 02:37:03 -0700 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 16 Mar 2022 02:37:03 -0700 Received: from fmsmsx601.amr.corp.intel.com (10.18.126.81) by fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 16 Mar 2022 02:37:02 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21 via Frontend Transport; Wed, 16 Mar 2022 02:37:02 -0700 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.172) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.21; Wed, 16 Mar 2022 02:36:59 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GoA8ohTMe2r0Ppml1WnUNuxfwYseMtNzKwx14EPJ+SWvH1hg7dtCLb1nCWbzSpu48KOs/wSbsFMSdyy7SndQdTB76KYBFd5xqbmRu7YrNG/jJm3kJHXzLoxbYSqDPUPs5E+jmKqkxo6B/Wef8e1XSrxZecs3FJqPocA0nTU41l3GBzB7bJWonL/FQ48r2psyxVSpuaON3I2Qwql1LG+2panF/J24Rgh+Euz9+CH68IjPuhDKK3dSOFcwHt/XYkWUIGhnbez0kd4yrXrFPjxNiaxk1Pi0H87Cl5r35vXMkHeJGLwsrtvxyiq8A9iTZNpUpo5wwfV9t86/B7vsNZs6Dg== 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=4pEDEbHvuvgaGUAGKmfanAqz+KFwTV28qaECKw/TR3E=; b=SkJulSR56FDnlu41mH6P2vJGygJq075zyzbvDdzxCy6WyEFXNkPByw4ZA8m4H2KPhVrcCtnZLwQ4FZ6Ct9bd+J3eD4Yc1yLg2TMbAig+EgjoeYDAlMV1em0XP5Qx43vTQLQJceUeZFb3MOknG4iyFXJrvlyayOo54SAMCnePv47KUn7M1c5uJ0LOtiDYwAP7/vioIlQevjP5hk4n5p9W+veViChQkVL5ifhg2ahG0FeL/wYto4e52EfZKGpK+dtC1V9UsScJCP251bIbcKvDMb5lvjSVI452WRp5tbaopgpEWvk9BO1QtOERHEhQsZPtaG8z30oG8cdQfWSgIwLWMQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from DM8PR11MB5749.namprd11.prod.outlook.com (2603:10b6:8:10::15) by BN6PR11MB2003.namprd11.prod.outlook.com (2603:10b6:404:46::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5081.14; Wed, 16 Mar 2022 09:36:57 +0000 Received: from DM8PR11MB5749.namprd11.prod.outlook.com ([fe80::8072:5ca1:297a:f7f9]) by DM8PR11MB5749.namprd11.prod.outlook.com ([fe80::8072:5ca1:297a:f7f9%5]) with mapi id 15.20.5081.015; Wed, 16 Mar 2022 09:36:57 +0000 From: "Metzger, Markus T" To: Andrew Burgess CC: "gdb-patches@sourceware.org" Subject: RE: [PATCH] gdb/x86: handle stap probe arguments in xmm registers Thread-Topic: [PATCH] gdb/x86: handle stap probe arguments in xmm registers Thread-Index: AQHYOFsrWTZ0152K8EKUVAIExYX4/6zAW+xwgABXaQCAAMWhIA== Date: Wed, 16 Mar 2022 09:36:57 +0000 Message-ID: References: <20220315105446.3348835-1-aburgess@redhat.com> <87ilsfunvh.fsf@redhat.com> In-Reply-To: <87ilsfunvh.fsf@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-reaction: no-action dlp-version: 11.6.401.20 dlp-product: dlpe-windows x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9eb6f263-1d04-4204-426b-08da073083d1 x-ms-traffictypediagnostic: BN6PR11MB2003:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: T2flw5xUJ6nbY56p2qs8wZygvq1vD6YrtW0YaT2ugwAGKuDmrkSAbTnAp99GhwEuFH8BIYqLBlhk7BNoCJT00qc/8XQYc8F8JS14rRUMcqHgb5A4gIkx33h/mDGrNxd+taH5cjxzwDRPHujML4MFTboxMLYvtteW+XtXa2VyaxKvoOlHp10pNSWVcPHtaUZS98zazifbUAE7kfMozd4GFderPS7BhXNkDxZgFkfa/IphpMWyA3AfUhERSYbhMzK2xXmeN2PNjJmq01LscuJaUC4+EkbCl3zcxs7G2oZ9o2mfW9dXrZfBZKgy7oRFcpChJeKjEgtqphmuBoF9qBaiMw8UQOTew5f/xVG8ftUPBFMgW5czKiUwPX7WJ122nON6JdqV0I7D818Qqb3jZ+MGlpHuN+MUdaQjzE5pFBfkcuGgO8bKU421NmMJGo6PePxPjaTek+EXFMvaJZ9tmKKao7D5RUw5C8fHLn5EpCdeAosGKcNE7V2+QrZbZvaJcQhQ2Ec6P9hDatfm7sRSyAEElDK2xXW3HTz7F157JOEtfZKpCX9YYqU40fDRhJlufZGlwXpRYpIMtE7CD/xAIcG7im9h3MPpSG2zG0C06cX8/oVPocJCEdYKjHWuaarDrTzk05X1s44eUoTC2LWylLh5GwOvWB6gvBLe8S2a6iJslIfverRZm7jMW72rabEvPdaaVoMIR//uSj1UirVTXbVPotr+PjdIKcIb/Je3sKIe3d/xzrB3jcxD/Z1AhC+ww9cZBPjJeKRIA19Cz5a0h/M/bry9ZtA1H055zzoP8n3+g/s= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM8PR11MB5749.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(5660300002)(38070700005)(26005)(186003)(316002)(6916009)(52536014)(83380400001)(8936002)(76116006)(66556008)(66476007)(66446008)(64756008)(8676002)(66946007)(9686003)(4326008)(7696005)(6506007)(84970400001)(71200400001)(508600001)(33656002)(86362001)(55016003)(122000001)(82960400001)(38100700002)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?kZH7Gm7dbaeaEzTgxc+gJE/VCmyFv5znwtP1CfdxXFNVsxU5xxhELqd/KTVx?= =?us-ascii?Q?swYYCMTrq8/weT/6L9J1J4aA9GygxyI1XnlXGdP04YfYYvM9mLK8qRegPrf3?= =?us-ascii?Q?2N1ELqEmjhwWVfexoW+FH3Iu1qUnrvOJKWtWO9sIsYHBjUOR/ogwLg/1CXsG?= =?us-ascii?Q?ZG5AQFlt1wbEgTqyLxPGUTFc2uzjhMHOJ/RLIMsKD8kJVbVSM//3j1t7vj2u?= =?us-ascii?Q?C98LxMXk0PsdpT5ynvnmXreyYQTGQmteAR+WswRUHPw6ZwGNcIpu9a1oysm1?= =?us-ascii?Q?88UVguvOtWFSwGsfH7hedw84f5VDUpfgl3+J6W3nhs3u1P08z3Aadpigw36p?= =?us-ascii?Q?6ngPK3/+VscNNeTNXhh77IHfa+qKZV4sRcKIMcLyTgjr9a5A2ardOTEgXf6w?= =?us-ascii?Q?IcAEcPiLuzdkXerJdFcQ6rO3DcERs+qq5InD7NXZ5/BVwOWfYLaHmzU1wXmY?= =?us-ascii?Q?TNPn2nxRGw0qsLHhDI24U3z44reMEHNuMQOT+NxApc0YMPcvMC4THxhdz2pW?= =?us-ascii?Q?OxkixcP4LmTlc8zzjKdXufQ+Fxv4QAYjN1EplSQFqQPtZBcrv5pM70sgJqhx?= =?us-ascii?Q?8Fffo4he4Uxf5sJSa2ZgJD9m5+INO2300ZB7J6LTe6X0h9WvJvigRsXy11QW?= =?us-ascii?Q?KvaA5cKCZ3zjLnoppLC7STG3WLjdW2TVkwJ+BkM2mMKm1CBvoHsQ0pmYzI+s?= =?us-ascii?Q?CiLxSusN3LJrkX3s+N0ynNu00wi152xxX4SUTOiiL+ePG28JcjIyPePwTI7Z?= =?us-ascii?Q?aKiEJey3HHADxCV2U8nd7bx7u/md8WATtPVoNx9AqwATU/y9+etADtR65ky7?= =?us-ascii?Q?+HJ0FoSTtaQOCWlHvdxbkr3Au1U+aEDtQq4inWhnsRN95qtdwk2IpnCqbfG0?= =?us-ascii?Q?ZR/AV4dlLEDn7PHXpE+e5XGQHO5Hja5jmKek/gjzySu3MheXUs/yYb47bt/J?= =?us-ascii?Q?8ZkXtqPp7K3b7RRHaQYbJR7zECvq38PuHemZbPuWgNR8pjq+yMJkM6ywZUew?= =?us-ascii?Q?srh+fvyFNhG+Kiu1+w/fam0VHoBWg1Fz8hojZzQYUG2pCV3waNtQucu6hlKm?= =?us-ascii?Q?+ocUvYmTUKYo4Vli9XLLJy+PMA8AA3se4VwRGlm5Dedmyzwrou4aOfwjA93m?= =?us-ascii?Q?CsrlTeG2E/J3y1NvjsA+dVGo2LbXffyPMItVxJWtDfRovKN/WukP3QZOlwVQ?= =?us-ascii?Q?l8IqH8LtiGNqHS4T+0SaFp2iuGol08t700FY1l20KY1GYs0T+Le7MtzcVUMR?= =?us-ascii?Q?/IGVJ2kQZYgJybHbcJ66LC4ntee5xDt3THEpbcS6gc9tl1XZ3+eBH4US3FPS?= =?us-ascii?Q?wSF5gM10a0Ol58EXiQFvk6R2034iXxhZRfjhyQoLYnGNEBzNQniBfnpzfMK3?= =?us-ascii?Q?RDENUd423vUDvHN1vQ0VXkAJELU1mHMXudjMRwOq+O5IROP9vgQ94ef0iM6D?= =?us-ascii?Q?AdsV7MPMvTBuAjg5rp45muRp2rOKb+Yzc1xRiGSGqTA8rABud3oMxQ=3D=3D?= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM8PR11MB5749.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9eb6f263-1d04-4204-426b-08da073083d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2022 09:36:57.7388 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rV53GXUDD7uAFpwELOauxqCje0vd3nt/mlta39U5MT2RmnTs4NtA9g3WTLGJ7XTeyjGJ9ynWy0ljGbdOmNLIBP+Y26Fefeb2PkQ4p4yEtag= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB2003 X-OriginatorOrg: intel.com Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-11.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2022 09:37:08 -0000 Hello Andrew, >> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp >> index a35d08a05de..ab7058121e5 100644 >> --- a/gdb/testsuite/lib/gdb.exp >> +++ b/gdb/testsuite/lib/gdb.exp >> @@ -729,6 +729,12 @@ proc gdb_continue_to_breakpoint {name >{location_pattern .*}} { >> >> set kfail_pattern "Process record does not support instruction 0xfa= e64 at.*" >> gdb_test_multiple "continue" $full_name { >> + -re "Corrupted shared library list.*$gdb_prompt $" { >> + fail "$full_name: shared library list corrupted" >> + } >> + -re "Invalid cast\.\r\nwarning: Probes-based dynamic linker inte= rface >failed.*$gdb_prompt $" { >> + fail "$full_name: probes interface failure" >> + } >> -re "(?:Breakpoint|Temporary breakpoint) .* (at|in) >$location_pattern\r\n$gdb_prompt $" { >> pass $full_name >> } > >I wonder if these checks would be better added within gdb_test_multiple >itself? Good idea. This way, they also cover gdb.base/unload.exp. >>>My second plan involves adding a new expression type to GDB called >>>unop_extract_operation. This new expression takes a value and a type, >>>during evaluation the value contents are fetched, and then a new value >>>is extracted from the value contents (based on type). This is similar >>>to the following C expression: >>> >>> result_value =3D *((output_type *) &input_value); >>> >>>Obviously we can't actually build this expression in this case, as the >>>input_value is in a register, but hopefully the above makes it clearer >>>what I'm trying to do. >> >> The extract approach looks good to me and I can confirm that your patch >> fixes the issue I've seen with dlclose() and the probe interface. > >That's great news. > >> >> I was about to try changing the register operator to provide the >> expected type but then I started wondering why we would want to >> assign a type to registers, at all. A register provides storage but >> the actual interpretation of that storage is left to the instructions >> that operate on the register and, as we can see here, compilers >> may use that storage in novel ways. >> >> I see how it might be nice to have some default display type for >> printing values in 'info reg'. But also that has become a challenge >> with vector registers where we interpret the bits as vectors of >> different length and element type. >> >> Maybe we should leave it completely to the command that prints >> register values (e.g. 'info reg') to define the type in which to interpr= et >> the bits (e.g. via a set of options) and leave register values themselves >> untyped. > >I think I'd need to understand more about how the proposed UI would >work, the current mechanism has the advantage of being pretty intuitive >(I think) for users. I guess if the vector registers were presented as >a single scalar and the user had to cast to the vector type, or set some >options, I fear this might be harder to figure out. For vector registers users already need to know the element type and vector length they are interested in. Today, they get it all at once (gdb) i reg xmm0 xmm0 {v8_bfloat16 =3D {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v= 4_float =3D {0x0, 0x0, 0x0, 0x0}, v2_double =3D {0x0, 0x0}, v16_int8 =3D {0= x0 }, v8_int16 =3D {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x= 0}, v4_int32 =3D {0x0, 0x0, 0x0, 0x0}, v2_int64 =3D {0x0, 0x0}, uint128 =3D= 0x0} or (gdb) set print pretty on = (gdb) i reg xmm0 xmm0 { v8_bfloat16 =3D {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_float =3D {0x0, 0x0, 0x0, 0x0}, v2_double =3D {0x0, 0x0}, v16_int8 =3D {0x0 }, v8_int16 =3D {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 =3D {0x0, 0x0, 0x0, 0x0}, v2_int64 =3D {0x0, 0x0}, uint128 =3D 0x0 } or they select from among the options (gdb) p/x $xmm0.v4_int32 $1 =3D {0x0, 0x0, 0x0, 0x0} One could imagine formatting options similar to the 'x' /FMT options, altho= ugh without the repeat count, which is implicit in the register size. E.g. (gdb) i reg /xw xmm0 {0x0, 0x0, 0x0, 0x0} This would also work for general purpose registers, which may contain vecto= rs, too, e.g. (gdb) i reg /cb rax {104 'h', 101 'e', 108 'l', 108 'l', 111 'o', 32 ' ', 119 'w', 111 'o'} Convenience variables (e.g. $xmm0 or $rax) are variables and would hence st= ill be typed using the type defined in the feature xml. Registers would no longer be typed and would be printed as a stream of bits in hex unless specified otherwise. OTOH changing the UI is always difficult and there's bound to be someone who doesn't like it and someone whose scripts all got broken with that change. Also, we would need to cast untyped registers to some type for any operatio= n like adding stack offsets as in 8@1600(%rbx). It is arguably cleaner as the typ= e now comes from a particular interpretation of the register's content rather tha= n from the register itself, but that's maybe hair-splitting. Regards, Markus. Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva = Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928