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 071FC1F8C6 for ; Fri, 6 Aug 2021 09:05:04 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E4156383B424 for ; Fri, 6 Aug 2021 09:05:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E4156383B424 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1628240702; bh=3mlN/brFmjBLUYkkDunByl4dKcMXkjXQatdNB9GvKD4=; 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=hjcU7F+7AI+hYo5+m3R7WsyFrpxhxjgE080tqsEvNOFGM9FnXWY4DS4CIMi3Dz7wC gAn3eCZsEa12OaRAAc6ohEy5+TfDHHLxviriwckTss8ujEJo7hKUAx3E7jdd3C8ELF pS8Ax9oUR842/daXVpdATlQk7duuuWzlk1MLtGmQ= Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2051.outbound.protection.outlook.com [40.107.20.51]) by sourceware.org (Postfix) with ESMTPS id B08CE3857420 for ; Fri, 6 Aug 2021 09:04:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B08CE3857420 Received: from AM6P194CA0004.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:90::17) by PA4PR08MB6093.eurprd08.prod.outlook.com (2603:10a6:102:e8::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.15; Fri, 6 Aug 2021 09:04:38 +0000 Received: from AM5EUR03FT020.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:90:cafe::b8) by AM6P194CA0004.outlook.office365.com (2603:10a6:209:90::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.15 via Frontend Transport; Fri, 6 Aug 2021 09:04:38 +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 AM5EUR03FT020.mail.protection.outlook.com (10.152.16.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.15 via Frontend Transport; Fri, 6 Aug 2021 09:04:38 +0000 Received: ("Tessian outbound 7b804b1d9bbf:v101"); Fri, 06 Aug 2021 09:04:38 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: b588080004d0f050 X-CR-MTA-TID: 64aa7808 Received: from 71c9e8e1bc7b.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 4F87CDAE-4641-4658-81DF-14DFED4AF5D6.1; Fri, 06 Aug 2021 09:04:30 +0000 Received: from FRA01-PR2-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 71c9e8e1bc7b.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 06 Aug 2021 09:04:30 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YwXG3yZoFz4ML0l6aLJcz8GBq7pRrkxEeROejR5IzmXSSKzHdUNXXoKirFQZ2l33RDHEXSlYqKbKgDdExfDrl3DS+V5s8ymzE8YhY8/7i/oPsXz5FofjzrcQ9feEKFh0TM1Votvyq6ZDbdNUV3GMerTHl8X5y9/+I74mnJbMA3ugEd7d8+S905Lny33jx3pWu0WEWUcbHlGw6JtNF3cnRhZX594gURuq0j+XMLuVzJ5mADc2JU1Bn1SG5BFqWubwWBAOA6sP10FkxQVkBF24eyh2B//hnrRk9FMdP20EL8GsWXi2GRge2nSzUoxK16mC13sGxlSfazpAgjiSHIw9Hw== 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=3mlN/brFmjBLUYkkDunByl4dKcMXkjXQatdNB9GvKD4=; b=oaqsvq+PlaNcCzSKdhCMqHc4eaGQLXfyB/LBxiiCEOik8NE1oAYDu9/WRMMsB4u74b7uh+fnaZtiObx638XKvBoKHNhi6DCLz+lJBBSOiBkthdHvz7MbtXExBjagvwt3ENKNcANOC7wtF7rEGAa+B0vvNoSSR2M2F2HaArh4cecdVKh369ZI5ZSTyMkYS2VqvRyaiWktDQFQnJRt+RIpGrrRAteuI+HB0+tiJajnhqf/G+N0h24Tefw/m/sq+ewTCNvqFADRqQd7CUZIABLb5EMlQe6i3Wx9/uqnZqhpEaaIOC2LHC+/115ToyYWMVDxy5LbXzlAIHDIJT8civ39jA== 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: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=arm.com; Received: from PA4PR08MB6320.eurprd08.prod.outlook.com (2603:10a6:102:e5::9) by PR2PR08MB4826.eurprd08.prod.outlook.com (2603:10a6:101:24::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.15; Fri, 6 Aug 2021 09:04:28 +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.020; Fri, 6 Aug 2021 09:04:28 +0000 Date: Fri, 6 Aug 2021 10:04:19 +0100 To: Ben Woodard Subject: Re: A collection of LD_AUDIT bugs that are important for tools (with better formatting for this list) Message-ID: <20210806090411.GM14854@arm.com> References: <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> <20210805103243.GJ14854@arm.com> <7A99614B-28D1-4173-BAE8-8EE561BE13E0@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7A99614B-28D1-4173-BAE8-8EE561BE13E0@redhat.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-ClientProxiedBy: SA9PR03CA0019.namprd03.prod.outlook.com (2603:10b6:806:20::24) 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 SA9PR03CA0019.namprd03.prod.outlook.com (2603:10b6:806:20::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4394.15 via Frontend Transport; Fri, 6 Aug 2021 09:04:25 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3a288ff0-2903-472c-c520-08d958b93840 X-MS-TrafficTypeDiagnostic: PR2PR08MB4826:|PA4PR08MB6093: X-LD-Processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true NoDisclaimer: true X-MS-Oob-TLC-OOBClassifiers: OLM:9508;OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: AZKJ64KfUhbxhh7BdcKP2x5E3VxyHzeBj2jKTtMtNnoZo/+F2UE0Hd5k061ihxsP7X+QIGXtkxFO47KMw3SXEd46uj4Rhcz+gutF41EFfXYGIERVyds92cRzaMxyzHg3t2c0PL+pH87lhE0vNY8A1F5ON7F1V5Yan7x3mnI4+tZ9EcAlNgy59dsjshBRAClKGj8Mnw2nP7/O/0oaVoUYhPlRG0Rk1CGWPi/UlSb0LyprJ3qWchllPldeap2n77oMcixvhxfis7VjqvtdEwmZmBXg7AE+W9Pzr2xW+7baLEHHQPPZNsLFMRbqHTWVFdLe0w5Eek0nqdg8DBfc5XeoL6qLSSbKfJq5UpPAAPX7UPNN3UlyrcRa2Krxd1+mj6YHfBv0lsOW3+sRbNn6fuoI430B9p+YSrGzv+sFLUSAKZKEUqplLT67ZZaOdp4TjWNV7f7OUFGOKouoHQt9K5KWcyz+J183DLJJTfh8e+CFuMv/SDMdUk5g7P30sfOf3kIu8qAe03gF/+gClP2oFCmI+qxsD0KGJPKjSFR/2+lngah1ZjFqgy2BHOoruG7PBr0uo4QHdPZpoRods9ex0hoGoZZNPWrr++IXooDvlC3HiWoE4LN9wirf7h0oQ6P2vYzvgYZukuCm58lkBmQpgS/qFZcaIBIDmUd5CzUAVIRrzEKkZl6aw2Cg722g4ViC/zjVLM+YAHq8dhpzQA7xH6ixU8SlMYAYedlbrnrTUmG9cklqD7lg701CNlS+GtNBP1I29zHO3k5mzxgihejSMsONNcTYogirjrcwtxZvq2QmvE7jZBCKcZmHH6Dwj65ofYWNt7EJmxKIkjY/Av8kFNOQ1A== 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)(376002)(39850400004)(346002)(396003)(366004)(6666004)(966005)(316002)(8936002)(5660300002)(4326008)(66946007)(66556008)(44832011)(8886007)(1076003)(26005)(186003)(6916009)(2616005)(478600001)(66476007)(54906003)(956004)(33656002)(55016002)(7696005)(86362001)(38100700002)(38350700002)(8676002)(52116002)(83380400001)(36756003)(2906002)(53546011); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?L2ZqMFZmRTdzMERhVHh1YU4zOHBhTGFFcEVPTmwyaTc5STJwVTJ0NFdyekJk?= =?utf-8?B?blh0MTd1dnIyZzJxZ2hSZWtJQ01oZXFGd0hOVjdKSjFRbUhISFZXVlZ2dHFk?= =?utf-8?B?REE4c1hURHpsNStZKzJMSG5MU2tlR2N4a0JUWDJDdmcrTW5hek5kWXRnZm1C?= =?utf-8?B?cENLWEx2RUdoNjNrcW85RFlQbFV6b0FMbEpMK0VGOFNCYmFITXFreW0xUzIx?= =?utf-8?B?U3RkM0VOYnVpUE5OR2FCSnZxUUMwRmk4aENtWmd0aFZnR202Wno3SG55NWNN?= =?utf-8?B?QUl5U3BBb0t6c09Bd3hHNkxpZkNlalpQNnJzd2hXNlRaNUlCblZhMkhYbEh1?= =?utf-8?B?cXFPRms4QkVuUEUwNlVjRk1aWWkzTmVrdXNrK2U4RnQwN2tJNEhGQytGUGNV?= =?utf-8?B?Sk15eW91aUI4WWxvK0xLNlhHd2JuV0pNc0ZjRW05RDhuRDArQytZb2RGL2cw?= =?utf-8?B?d2NXbWlmOEowSHB1Q3E1RjNHWEx1QVhQYlNSMGNaa0VtRUN0RElRRXpNL1dY?= =?utf-8?B?TnUzZFIvMHRwK1pRVHdqeUJPQ0t2WStiYzNmMUdIbk1Ec214YTFBbnFoMTNj?= =?utf-8?B?UlpFS2pDQmZKVnZGdFM0UnZodGQ1REZ5WnM3Ky9FblpNaDhjcnNTWHF6bUNN?= =?utf-8?B?N0RDcnRjS2lFaU9md2hZUDRqTUpKNFR2RHhrM25GNTdPVk9hZmlVTGlRMDhi?= =?utf-8?B?N1EzT3h6dXZ5RjQwa29pWFFsZWdsOEt3WXhVYXJPMU1Wd2x3R1FxNjRyQ2pW?= =?utf-8?B?cmpQUTRrcU1nbm9yRDlmdnRNS041WUR2alN3ZHl5bnQySUsvZFpxQVZVOGh2?= =?utf-8?B?WDZtVUpCc0ljVmFoakoyUTFPWjZzRXZBNUE4VldFWkc1NkdpM3JKdnV6dDE0?= =?utf-8?B?UjRuL3pGV1Y1M1dhSFNjU3hQcXFwTFQxaU9BODliOTc1MWcvUUoyYVZSRU9C?= =?utf-8?B?Nmw5SnBwR1M0Z3BTMVlqVEVUd1pTdDBWampnUHVocVRrTStXNkZjY2lFR3NV?= =?utf-8?B?RjB1NjdXSjJVN1l1QklCeUxJK0NCbENjVUU2ZnRoYzM0RU1CVHQ1aXVnQTFJ?= =?utf-8?B?SHI4NkNEUlVHV2RSTndxREZsKzVvam5XWWdJOStFaHM3NldOV1Zrd0I2M1o2?= =?utf-8?B?QTZtb2E3bVpYMWJ4MDFpS1lYWmxOeUkxTUV2aUlqYVo3V08zUUxnOGxORmVv?= =?utf-8?B?QmVJV3NOZjlMcHF4UWMwK0tjUmRqdVI2Y1kyOTdrS2xwTzJtS0F4dktyT3pR?= =?utf-8?B?NEdSZkQzL1JrQ3N3bUxnWFYzM3BEby9Ib1ZvekpBSW5LdTM1RGpUaTA5NnlB?= =?utf-8?B?VlpVY3RjTDNwR2htV21nb2dzZnZFMTd1TVBmVmwyR2xsalZYMGsrNFRpaXY4?= =?utf-8?B?bmlCVEJrMXByQytpZFhYY1JlNTAzdWNrdU5VSGQ3WEFBSkdpeXF2ZHg3N00w?= =?utf-8?B?LzVxekJIVGI2UEUyL05NeTA0WEF4M0Fub3Q4QkhSdDdXa1dYUmRMbTJOcE1l?= =?utf-8?B?bk8zV0NEL3NoNmpXZnhabTZmV2laK0U3VDZRMDZEdnF1TW9OT05zOW9IVndD?= =?utf-8?B?WmdGaStxUzhDWm9sVTBFRnRKNkdSd2dQZ0NuK3BqMDB0ZDlwd083Wm4xT1pX?= =?utf-8?B?M1J3Nk05YS9YdXlrblZEVjVBdmdtUnRFa1hnWStwQXBQS2ZEbHVMbGViZi9W?= =?utf-8?B?VmRibDk3bFpBUmpGRlZBaFdxejJxejlEQ0lwYjVweGdnTlNPb2kxdVJnWjlp?= =?utf-8?Q?wxssYxcXViQfUtX7igoTe2QNKD//5ZeyVEF1Hxp?= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR2PR08MB4826 Original-Authentication-Results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT020.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 89c53d37-8b2c-4569-9c8a-08d958b93198 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Lanp8SkRKUIBNw/bU2m+xx6t6GaypuNqyMxfgAI9qN5XZuHCveEVEDDNfUuQYTv6tEd0lBxNDK9G3EInbKjlRDvvyRFQbh/dEd0+oj4BpFwxn9UPTyLxSQtOVy8Z+vl0xnQiuiJGxCUxHL2ro2vyJZta3a7ZE1ZZ3X8EQrR5ptjH4o3ecrmb2Sbf4iBylnBy2Tvm7yJjYtJ30Ca1k/dgfDbkDlEqGlAgYXebG1URGu5Nqc6cPHX2qI5ZMBIvKhWXGQRQ3TMTRDvNsQ1RTqZa8RY9ZmA7JOojLOoc+9qwe9ZDa/2BECTorXkJ9T37dl3ANAD8rFwwr/f/cJHsB4zISRYDGv1aYyWR98BHOtNYs1B6STVdonp+77VtQ4M7blm9fnuVEyB72eNvk2v6pE2h6oTJVWXJ0CWhEJ34HgKGS+oOJ560xwJIqdY0m+SPzWkpOs2lMUzVNS3THQO+xISaGa7OwpLJukPaTseIBPg4Hxx+ifMrH4hEM2MDf+mhgGIHJt2w6+BGlrTDM7dE5pxyZNcMHeXrQR5nH90pEA2Yhmb1xq3q4s7ce8j4SdJPum6fM4usZMpBIxWyE6OFP5GgF5F+EjiAMiCTMCrI5uo81u51fDcfu6MuoeS9eUmgq8prrEMV772rt7N8NAuDBXRXQ1BXbr0dANTabCEZR54ZIHl6tP+bzv6L8+iHTBUa0mpq1CCBRUC+B7zpACpYShLNFsm3U66pYP1PLZF0VwmVPmfx7vnU2xsXZhXwv++TuKMau8hYCFNV9MX6glX2FYWl6XkzdBjjmP0FtO4jEJ4RQpFZ/OmLSMZS6ef+avshqrjhALslha07+iL7B5pul6fHEw== 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)(346002)(136003)(39860400002)(396003)(376002)(46966006)(36840700001)(82310400003)(8676002)(36860700001)(6862004)(70586007)(81166007)(86362001)(356005)(33656002)(47076005)(36756003)(70206006)(82740400003)(4326008)(8886007)(2616005)(966005)(83380400001)(1076003)(7696005)(186003)(53546011)(5660300002)(2906002)(54906003)(44832011)(478600001)(336012)(26005)(6666004)(55016002)(316002)(8936002)(956004); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Aug 2021 09:04:38.4799 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3a288ff0-2903-472c-c520-08d958b93840 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: AM5EUR03FT020.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB6093 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/05/2021 12:36, Ben Woodard wrote: > > On Aug 5, 2021, at 3:32 AM, Szabolcs Nagy wrote: > > 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. > > > > Yeah honestly this is why I really believe that we need to define STO_AARCH64_VARIANT_SVE (or something like that) and go through the pain of changing the compilers and binutils. I do not believe that my users really will care about the full breadth of STO_AARCH64_VARIANT_PCS and all the potential strange ABI variants where all the registers must be saved. I also know that they will be willing to recompile any code which uses inter-object calls that pass parameters using SVE registers in the case where they want or need to use performance tools which will go through the audit interface. > > SVE parameter passing is defined in the AAPCS https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#parameter-passing-rules while all the other PCS variants don’t obey the AAPCS. I would argue that using STO_AARCH64_VARIANT_PCS for inter-object SVE calls was a expedient kludge that needs to be backed out. > > Having a design that can ultimately accommodate all the variants including ones that do not obey the AAPCS is great. However, the only problem we need to solve in the reasonably near future is being able to audit SVE calls. If and when there are changes to the AAPCS, having an extensible design such as yours, we can handle those too. (For example: I cannot tell yet if SME https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/scalable-matrix-extension-armv9-a-architecture will ultimately lead to changes to the AAPCS but if so, the changes do not appear to have landed yet.) we thought about marking the exact pcs separately, but 1) we did not want to reserve the available STO_ bits for pcs variants (there are only 6 bits and many potential future extensions and pcs variants) 2) we did not think that plt hooks will want to know the pcs in more detail than just marking non-base calls. plt hooks seemed to me unreliable and very rarely used. if we add STO_AARCH64_SVE_PCS then we need _ADVSIMD_VECTOR_PCS too and possibly SME variants soon. and each variant requires their own PLT0 entry: the STO_ flag can be checked at load time but not easily at plt entry time, so separate plt entries are needed. and each new variant requires a glibc update. this approach was on the table, but i considered it overkill when we had no usecases. > > 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. > > uuugh — my users are all HPC users. i think we need to do some measurements how much overhead it is to save/restore all regs for all calls. and estimate how common it is to have elf modules with sve calls in a hpc setting. > Really, it comes down to I’m not a fan of DT_AARCH64_VARIANT_PCS for SVE inter-object procedure calls. I would sort of like to leave it unauditable and just move SVE into its own variant. However, other than SVE I do not know of any other uses of DT_AARCH64_VARIANT_PCS. Writing assembly where all the registers must be preserved is such a pain. i only want to do the SVE marking if we have no solution with existing elf abi. > > 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. > > > > Tools that actually use the PLT hooks are very rare — even more rare than tools that use LD_AUDIT. The ones that I have seen use that interface to inspect and modify parameters and return values. So I would argue that providing RW access to the Z registers is required. > > The two broad categories that I have seen were either trivial and used for basic curiosity and debugging (kind of like a targeted ltrace) and ones that worked around bugs in the libraries or did additional security checks not implemented in the library. The latter seems to be what the PLT portion of the LD_AUDIT interface was designed to do. Quickly coding up security bandaids to detect and prevent exploitation until the library could be properly fixed, has been really handy a couple of times. For example, I wrote one a few years ago that detected prevented a buffer overflow in library where fixing the underlying problem in the library required an API change that would have required broader refactoring of the application. (IIRC that was libpng or some graphics format handling library - the effectiveness of this solution was limited by the fact that glibc and binutils didn’t yet implement DEPAUDIT.) i see, i think these can work with variant pcs, the main question is the overhead.