From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, MSGID_FROM_MTA_HEADER,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS, UNPARSEABLE_RELAY shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id DAC541F8C6 for ; Thu, 5 Aug 2021 10:33:24 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 96693386FC3F for ; Thu, 5 Aug 2021 10:33:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 96693386FC3F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1628159603; bh=5QoJWHA5JqWMFTI80bzgaBqHlGaqe6JDZI9+ZaHvheg=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=qETy1BQ1pQ0zJUeHrvRtmoEt2ZDdfAEnhrxG3sLjrEgJTayHP7Ef7pwl/G84oCqIn 6uyf0zETwo+t5GSosIIfJnJgOZ64ajJwqX7giem8GtA9dGtwG57o6EEUGj6i4EbGBD 4mzxo6clzf8ueOCS24drgc+Y6NwVDfKcae/R7oQg= Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80054.outbound.protection.outlook.com [40.107.8.54]) by sourceware.org (Postfix) with ESMTPS id CC9BC3857435 for ; Thu, 5 Aug 2021 10:32:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CC9BC3857435 Received: from DBBPR09CA0040.eurprd09.prod.outlook.com (2603:10a6:10:d4::28) by AM6PR08MB4390.eurprd08.prod.outlook.com (2603:10a6:20b:be::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.24; Thu, 5 Aug 2021 10:32:56 +0000 Received: from DB5EUR03FT064.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:d4:cafe::80) by DBBPR09CA0040.outlook.office365.com (2603:10a6:10:d4::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.15 via Frontend Transport; Thu, 5 Aug 2021 10:32:56 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; sourceware.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;sourceware.org; dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT064.mail.protection.outlook.com (10.152.21.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.15 via Frontend Transport; Thu, 5 Aug 2021 10:32:56 +0000 Received: ("Tessian outbound 312d863716bf:v101"); Thu, 05 Aug 2021 10:32:56 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 00806f1f35b59c0f X-CR-MTA-TID: 64aa7808 Received: from 0c1a9d05d32b.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 38DBB5CC-F821-4E5E-9559-AF2D2B1E2906.1; Thu, 05 Aug 2021 10:32:49 +0000 Received: from FRA01-PR2-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 0c1a9d05d32b.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 05 Aug 2021 10:32:49 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AGfq27txQEP9Yl+fJ0JEncGSR4Y+sB9d6vI8EqgaN707j88/882bVH37tHFvkwsxILIma1uAeWEYJwo1lWA6gjHuduQoWpSheFb9o2MGDHybRGPZZk85EhGw/0jxwcaE32L30pCIjhLQFhIB3l4U5GFjmAxGHTViwEDsF9AW3y99KQGMBMBllKfGe66IPuTcRKUEVW+1/TwpTxuM3vob9UdYK2YqeOkqQ7QK8z7Ocr5ZABNQZG9Oqddf702CV9ysnjoWgiRHTDGEXT3l3xNiMZTxw8JXFU4Iz376t1UHOd2vfJNEX6JMy09y89Agn4nzdx6TZd9/NBfcnX4BR0Dm0A== 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-SenderADCheck; bh=5QoJWHA5JqWMFTI80bzgaBqHlGaqe6JDZI9+ZaHvheg=; b=bMyBy2LZnNiVqiM774TU5gLLI83Jm0YZiOTpVc2DjlvihZu/aO6huhWPU2JKwinua/OeQZ5TWTtzlxrQuSZBudJlPTJoOsWDQWRp3Af2/7IGqr3sSHuY7bx76z72L1xiwy8A58il6gAW/pqY1YsYrWT0RhSyD5E82deUNCX6VmALgHD6ApEneS5VYfAIXJohm2xBA4Ks4DJe3Lj9J5RszUmglj4r9S1/SDZwBimSrFlDdcQUhml+FOclWH8/lDbqAXgCvn8hnxxZd8OU5zYJeFa4AU5GwPS1+Zmp4gCeCOT2VL5cdD4s0HOgbAXfU5WpAEv1YRT6jgH30snldMjNNw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none Authentication-Results-Original: linaro.org; dkim=none (message not signed) header.d=none;linaro.org; dmarc=none action=none header.from=arm.com; Received: from PA4PR08MB6320.eurprd08.prod.outlook.com (2603:10a6:102:e5::9) by PR2PR08MB4825.eurprd08.prod.outlook.com (2603:10a6:101:27::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.15; Thu, 5 Aug 2021 10:32:47 +0000 Received: from PA4PR08MB6320.eurprd08.prod.outlook.com ([fe80::cd22:a583:c97c:72a6]) by PA4PR08MB6320.eurprd08.prod.outlook.com ([fe80::cd22:a583:c97c:72a6%6]) with mapi id 15.20.4394.017; Thu, 5 Aug 2021 10:32:47 +0000 Date: Thu, 5 Aug 2021 11:32:45 +0100 To: Adhemerval Zanella Subject: Re: A collection of LD_AUDIT bugs that are important for tools (with better formatting for this list) Message-ID: <20210805103243.GJ14854@arm.com> References: <8A8FF420-8316-4A22-AC4D-DA1F2D5625A5@rice.edu> <2fc830b9-35da-9b94-369f-4df683078a5c@linaro.org> <8735tguubc.fsf@oldenburg.str.redhat.com> <75b2e838-a32e-6a2a-27b2-75bc06c01118@linaro.org> <3F6132F0-1042-4285-A309-0365D014422A@redhat.com> <81b1ad4e-cda4-4ed9-61e6-6dc8884800d5@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-ClientProxiedBy: LO2P123CA0030.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600::18) To PA4PR08MB6320.eurprd08.prod.outlook.com (2603:10a6:102:e5::9) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from arm.com (217.140.106.55) by LO2P123CA0030.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.16 via Frontend Transport; Thu, 5 Aug 2021 10:32:46 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 89c1f934-e82e-4d1e-c3a7-08d957fc63cc X-MS-TrafficTypeDiagnostic: PR2PR08MB4825:|AM6PR08MB4390: X-LD-Processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:101;OLM:101; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: LFnuyT8ZVjXmoJ09twxkTOHnF7fIAkqoPtGJ3KHLYKBlRGzDFBvbfD9Pdw5ppIFwOB1+pmVVHdRG/IcJGqYYsW+2o23s+SEHiOcOuj4EZ+lEi+K2SV1bqDOzdBzU57jRkCRuzPmcUz120MM/v3WOazp2Zk1PL2bMAEFA3DLpo5xscWcABDFm259f8T+gvy6pq4Zlq87lxk45D7rxPj+jW3gYXsVLPhwZQ0I/8ldEMtl0x1ySSd8kUgy6H0wceVaX0qqolbKS+7GPNmpYY/+ntHV7M6rju2N8dA1D6ixKc3SGW31w9vFAln7hY5T2ICPeF65fzmCyqq5L0t86YRm6JPPVsTz8R96w60U9zPRNbUXmjjbsEC+4kVzv04J7PfikU/7Ea/iRFmTBgUnyyw/eDQO8lzPtJG8CaCH0+NaP0v5wKtHQilFYproGhzVO6YXzREJ61jrfY7AMl88BKH3E+u+Nua1JkUIcF2UTdNWjtKS85j49le6Ea++Kxwgkv+IoN8Ov5h8DTpAPfX36Clyb5OVMtagWFirtE4KqxgOEiJQhQ8U1nxja0iiA1xSjfJwtonG7jjgErS9CB//npoFT3THTRdi7UNIqwhAx7J9E/DUmVCtF928mUL9MDgFxlFLwzZnA+lQYAU/fj6Pm+vnZwlDD2Avo/ZoMcofgr24+oUEtRArmDNBXfp35JGsnoYeng32NMxA0y5945aA0SiCO7Zp4SvynmZD+d2PSPGVZNk9c/hp1UdeyCpy/tAS//1U0Ds/q2+ZC5P97i5SQbZnueg== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PA4PR08MB6320.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(366004)(346002)(39860400002)(376002)(86362001)(8936002)(38350700002)(55016002)(316002)(38100700002)(1076003)(66946007)(66476007)(66556008)(8886007)(54906003)(478600001)(83380400001)(33656002)(7696005)(966005)(26005)(186003)(6916009)(5660300002)(52116002)(2616005)(956004)(8676002)(36756003)(44832011)(2906002)(4326008); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ejVramRNTzFBT1ZLa0IzSVBLeGlSVDRGM09QMTVGNEx1b2VnY1JTQkFCSGpY?= =?utf-8?B?SW80TVZxOEo2ZnhsNzFOUXdHZmNFR0pHYWFDZXYvMHA1TjNFSFlLbFQyN1pM?= =?utf-8?B?NDVjeExueTlNai9hZDBwM3MzQmJPQVZFZTIyMVFObS9hM2JlWTJ6VFR4YmZJ?= =?utf-8?B?ZVJjR0xpSkZjbHdIbTVSR2MyM3MzbU5oMkJtNWYzR0NEdDFUMm82MXpTTm5E?= =?utf-8?B?Ujd4aFJuQTEzRW1xYkxJQ2U2QnArYWE5di9zMm1IZzQvcTdKK1hUWkhzWDY2?= =?utf-8?B?S1FUNGpwcTM1Q3Y2NHBBTmRqeWFscHJ2OFR3b1RPemduUDR2eGF4NitQSER0?= =?utf-8?B?Rm9KMjJ1VldIZlkrdDM4NS9wWWVhZGlzTGd6TkxqNWlaNVllVUZyN1dZeTNk?= =?utf-8?B?eGNObEUwN1FxTzh1cWFjcGMxU1VwZkVvT0pNdERUWlFONUV2aVFEUllRMjNP?= =?utf-8?B?OCt3Q0Z1MFlkeU8yK2FOT2dZYk9PV29SVTBwamlNMkdieDBmdW5rTWVja2pi?= =?utf-8?B?TzlCMHdhRk5lbFhlNGV6bmxlcEtmQVRXdkVHZyttK0VwS0syZjRySEo1ayts?= =?utf-8?B?VlZid0h5dEFiQjAyK0FJelo3YVJrSjhNbC93S1hqMm9HM05NWFYwQXhEUms5?= =?utf-8?B?K09Fc1JRcUJkWTlidjJKdHJ5b0RzZXpsZ0N3SGVkVGFadEo1ekZoOVpveEVD?= =?utf-8?B?WkNrMVBjc0JvWjJWWHJCRlI0Snd3UUFEWVZyMjFPT0xHZmpPV1pKd29sMVhp?= =?utf-8?B?Uk5lQzBWN2IrQ3psNUtFdU9JRzRabDFQY3NPd3c4dmxxSm50R2VCVGx3Yllv?= =?utf-8?B?VWpLVDhKT3hmVi8rUlhIQjYwN1hNQzNkeWNYU1NMK1gzRDdVcEsxbUEvL3Rq?= =?utf-8?B?UVFCS3M4aXlrM3EvY3JrRW5MOE1SeGIyZ0c0TldUbGIrWXoyU0xvSWFVeU8z?= =?utf-8?B?VkhET1VTdUYzK1gxS1F0RHlLQ3FtakN6ZVcvY2M4SHpLQW9GNnRnQ2l1dGI3?= =?utf-8?B?V2hDYnZ0QVJVR3BTS3RJWitMSWVLZWt6Y3lydGNSOTY5alJpVldJMGx2OWVz?= =?utf-8?B?T01ueVFjUjZ1ODdiSy83Y3JzSjl4WTNqdW9rNy9aWFhoU05OQXI4VTJzZVVP?= =?utf-8?B?eTNlUk5MaXIzNEh1d0pnUitrK0pjMytOSEY3SUduK2F4ZHhXa3hhcnBtV3lj?= =?utf-8?B?M0RBK0pNWThLOU1xcjl6NXltdnIxM2NwMmdTSnp3TXRpNUViUXBkUHVHNG5B?= =?utf-8?B?ZWhnRmlSejBQVG4zNWpLcmhOSUI5dDI1Y0hla1JaYUNtTHJHNWM4ZTFGdC9E?= =?utf-8?B?T2FBbjZGSzFIZHM1cDlSQmZSKytoOVNsbkJuMm5mdTBkVWF1UkhqaFZReUxL?= =?utf-8?B?Mks5bXJpOXRVVmVsZG94dlRzMUNndVhyMStWN3YxTDhRdWZNWTFhUU1YT2NG?= =?utf-8?B?ZmxMNzdacXM3bkdQVXFWRC8rWCt4QWxMZW8vQTY0c2VUUTBnd2xQRlQ4M3B6?= =?utf-8?B?N2JZb1grd09IVGlhQUtYTFNwMkZlV21UZDZrSHB2SHhKVUFXSDU2emQrVDA5?= =?utf-8?B?OG5HS2JGTWlITk4rN2R6OEdURU02SWc1MmxYMDFsamRBTE5DQnZEQSsvYnlM?= =?utf-8?B?QXpac1BuZlVML3VPOUlic3YwV0xoR3BtczVPSFhWRXV5RUhtcjdSbTUxeHFn?= =?utf-8?B?Q054cElqSUFIZFBLT1lRamJjWHpHRnU2WjdYUE50SnZrNGFWdFJpUm94SVBY?= =?utf-8?Q?w8Ev7BrR36F7a3Xw4+VtkkKYNzJT3sAzHLLo7Ey?= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR2PR08MB4825 Original-Authentication-Results: linaro.org; dkim=none (message not signed) header.d=none;linaro.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT064.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: a0f60d93-e343-415c-6941-08d957fc5e06 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: /anpluPW0kgadzzWPBbonSb6laUxtGMUcuj8jkMc7/EOe8w8d5KXz9fN0pyWMaObLhpkxkN6PlfODX2Jn2IMyHCQw8Oa5IgZ4j6ke3U4TGmbUaQ6uGM9FEPZET/bVhLVheX4ITL/+KroqzGrVlauk/glwjC/tEPvuF306JYsfdFWAOcRIEVrvwCRazkEZ29Fp2ZfAkdWuFnq+f3lXnyMCAR3KDsEzKoMJFF51M9Hnn3yI0wB8EpqQkg1DU1dulhVr/r/bLB4q+YB6ZNvDlydTqEJgmnL8Zm18aeh6VZu9RYXiDIkNJatnmaCeqNmgzAgC8N/wyXqnk+sUWUio5tj4YlFm5F3jx6/zCj8oU/MEUO0HddYQri2Arioh/sisEcHI55CxPVRaWfgBiDQ+x/wYg/uX4LBZG8pw3w6ldIcCYbfQU4PDxfLhNVlrNe8KwYoSvmOmsqRq9UR2nZ/hmL7YN7IUENxXtjo+3KTeligPRJ+49HuSE69p157cX/OTioB9JoflOLyN5dj9kMeJVshg0gfGAvFRBAOGm35wZEAwaSx62wptBGKBI9VeqYQbFbrFNz7oy21oteZ0X+zBN7fOlCnY1h9xYHe0TlOp+hR7awap38PSwFhBfCX92rNEYh42qlZPFwxOZlBuv/SitX7fgWulvHoCpVrvxQJQjaKntxLfn3lfM28D4IUR3DiRYA3+GlDkaRMMfuc9vaN4IrePM1d4iK5cj4lwSF/14edjN8C9Kpk4/BkmVGRBaAGt5XyES1LLAb0+1B96pje+cEWDQ== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(4636009)(36840700001)(46966006)(8886007)(54906003)(356005)(70206006)(8936002)(2616005)(956004)(8676002)(44832011)(508600001)(26005)(336012)(186003)(82310400003)(33656002)(86362001)(47076005)(70586007)(36756003)(1076003)(55016002)(83380400001)(2906002)(36860700001)(6862004)(4326008)(966005)(316002)(7696005)(5660300002)(81166007); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2021 10:32:56.7304 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 89c1f934-e82e-4d1e-c3a7-08d957fc63cc X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT064.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4390 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Szabolcs Nagy via Libc-alpha Reply-To: Szabolcs Nagy Cc: Florian Weimer , John Mellor-Crummey , libc-alpha@sourceware.org Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" The 08/04/2021 15:11, Adhemerval Zanella wrote: > I updated my branch with a POC patch to support SVE for rtld-audit [1]. > In the end the layout I ended up using is: > > typedef union > { > float s; > double d; > long double q; > long double *z; > } La_aarch64_vector; > > /* Registers for entry into PLT on AArch64. */ > typedef struct La_aarch64_regs > { > uint64_t lr_xreg[9]; > La_aarch64_vector lr_vreg[8]; > uint64_t lr_sp; > uint64_t lr_lr; > uint8_t lr_sve; > uint16_t *lr_sve_pregs[4]; > } La_aarch64_regs; > > /* Return values for calls from PLT on AArch64. */ > typedef struct La_aarch64_retval > { > /* Up to eight integer registers can be used for a return value. */ > uint64_t lrv_xreg[8]; > /* Up to eight V registers can be used for a return value. */ > La_aarch64_vector lrv_vreg[8]; > uint8_t lrv_sve; > } La_aarch64_retval; > > It means the if 'lr_sve' is 0 in either La_aarch64_regs or La_aarch64_retval > the La_aarch64_vector contains the floating-pointer registers that can be > accessed directly. Otherwise, 'La_aarch64_vector.z' points to a memory area > that holds up to 'lr_sve' bytes from the Z registers, which can be loaded > with svld1 intrinsic for instance (as tst-audit28.c does). The P register > follows the same logic, with each La_aarch64_regs.lr_sve_pregs pointing > to an area of memory 'lr_sve/8' in size. i'd try a more generic extension mechanism like in the linux sigcontext struct. then it's less likely that existing plt hook code needs to change when new register state is present and used. and i think we need to handle variant pcs in a generic way: we don't know if that's sve pcs or not. for example struct { uint64_t lr_x[9]; uint64_t lr_lr; uint64_t lr_sp; uint64_t lr_flags; // e.g. is this a variant PCS call? vreg_t lr_v[8]; struct extension *lr_ext; }; struct extension { struct extension *next; uint32_t type; // e.g. sve extension uint32_t len; // can copy the contents even for unknown type }; struct xreg_extension { struct extension header; uint64_t x[30]; }; struct vreg_extension { struct extension header; vreg_t v[24]; }; struct sve_extension { struct extension header; uint16_t vl; zreg_t *z[32]; preg_t *p[16]; char data[]; }; > > So, to access the FP register as float you can use: > > static inline float regs_vec_to_float (const La_aarch64_regs *regs, int i) > { > float r; > if (regs->lr_sve == 0) > r = regs->lr_vreg[i].s; > else > memcpy (&r, ®s->lr_vreg[i].z[0], sizeof (r)); > return r; > } > > To implement it I had to setup lazy binding when profiling or auditing is > used, even when STO_AARCH64_VARIANT_PCS is being set. Also, to not incur > in performance penalties on default non-SVE configuration, the patch uses > a new PTL entrypoint, _dl_runtime_profile_sve, which is used iff 'hwcap' > has HWCAP_SVE bit set. variant pcs does not mean 'sve call' it means 'arbitrary pcs'. so we have to save all registers. and a base pcs call does not have to preserve sve state so we don't need to save the z regs even if sve is present. the main difficulty i see is that we cannot easily tell in a plt entry if it is for a variant pcs symbol: you have to look at the symbol table entry using the symbol index from the relocation. usually such code is in c, but c code does not preserve all registers, so here it has to be in asm. the clean way would be a different entrypoint for variant pcs calls, but that requires linker changes (another PLT0 like construct where variant pcs PLT can go). alternatively use _dl_runtime_profile_vpcs entrypoint for an elf module that has DT_AARCH64_VARIANT_PCS set and then always save all registers present. then the default entry point does not need to deal with extensions. this may be slow for some hpc usecases. > > I think this is a fair assumption since SVE has a defined set of registers > for argument passing and return values. A new ABI with either different > argument passing or different registers would require a different PLT > entry, but I assume this would require another symbol flag anyway (or > at least a different ELF mark to indicate so). > > For this POC, the profile '_dl_runtime_profile_sve' entrypoint assumes > the largest SVE register size possible (2048 bits) and thus it requires > a quite large stack (8976 bytes). I think it would be possible make the > stack requirement dynamic depending of the vector length, but it would > make the PLT audit function way more complex. yeah, i think we need to understand how the plt hooks are used: do they actually look at these registers? or they only need the registers to be preserved? we may not need easy access to the z reg contents. > > This patch is not complete yet: the tst-audit28 does not check if compiler > supports SVE (we would need a configure check to disable for such case), > I need to add a proper comment for the _dl_runtime_profile_sve > stack layout, the test need to check for the P register state clobbering. > > I also haven't check the performance penalties with this approach, and > maybe the way I am saving/restoring the SVE register might be optimized. > > In any case, I checked on a SVE machine and at least the testcase work > as expected without any regressions. I also did a sniff test on a non SVE > machine. > > [1] https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/azanella/ld-audit-fixes