From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on2084.outbound.protection.outlook.com [40.107.8.84]) by sourceware.org (Postfix) with ESMTPS id 85F643858413 for ; Tue, 29 Nov 2022 08:27:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 85F643858413 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=coIwIbOIX9IpT/PEfXA/nQzppNgHYwzyME6kj6LxUuuBGLfZQoTszDVZh7VO+7MLsMAU8g+sZOqHm4mtQzjO+uLYInx1HNqTTHlIgjhCz764vXKeK2ZtLu2+rPqn2QfWwBX+Z4skgw1/vCfkNQ97krg9VeBHAa9OZbEkxCISx5jQl3dCPc9WqlsMF2lMeTGeXIG+79Mc0AU0nQDEUKT78IlhgmsGBt40kT2nxIJEzgPw8Ve3ev9kb6t22w/78Rd7ivNpANRNd3QH56WKW/C/9tpQDJ9+jjqPAdfkbR4DWuPUq4cu8pgVgHSuk4Xb5NyA0CK6rIYuesZYm2510tJ8AQ== 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=GN3qgnvTZJWpWXBbOazmJnN3vgZJ06/bu2IOkBUlZF4=; b=N36hdywnZ5RFZfUvu5cSBsra5BN/vWmP3ZkHeEnfwra0RewiPnvaeMhmJKMydp5ziO1tMYnAs1uhx7018nL4iPyUiaDfTINU5dWRQ051QoXGIkCfnvldySU0ObDUHGfIux/2U7xH06Fu3nF6apFE/E4t+LYa6pfur9B//0B/8CEfS6d8u6F8+yi+gf8cFfgkMJ31KDI3suV+FGuHLnOiTGieKuTBt8YjcVESGqRHLVa3GHUpxTrU8qMLKWOJ1U8X08DnrsNfhd1wmyg4OXsG2IQ9aGzEtN+w1gfWtgZu/Vn5WtIGXupVcHNGJl5LbpFvE3Zu7V2zHs0qfxJ0FW7pNg== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GN3qgnvTZJWpWXBbOazmJnN3vgZJ06/bu2IOkBUlZF4=; b=u/z21UGABCaTddOij4K1YUXCkCO7GE++AoSayojSN2oeLOYvMHNon8c2KM+x7FUwYOKJY7Dk+Fktm0p0109RfF+TOvHcsxD+y8On4MuCvRl807SlkNAU9unuh/viI0Tjj1asnB5AKxhlKYPtcHMf7ojL6/HGiLZLEn3eCVEk4ho= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) by DU2PR08MB10088.eurprd08.prod.outlook.com (2603:10a6:10:49b::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.8; Tue, 29 Nov 2022 08:27:28 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::fe5c:b195:a2ad:b19c]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::fe5c:b195:a2ad:b19c%4]) with mapi id 15.20.5880.008; Tue, 29 Nov 2022 08:27:28 +0000 Message-ID: <610ebe6b-64d0-d0c9-f9da-9e1445d53d73@arm.com> Date: Tue, 29 Nov 2022 08:27:25 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH] gdb: relax requirement for the map_failed stap probe to be present To: Andrew Burgess , Simon Marchi , gdb-patches@sourceware.org References: <9b1fe2f9-b4a9-17a8-1175-a1a776db1afc@simark.ca> <87y1s03a0a.fsf@redhat.com> <87sfi30zgy.fsf@redhat.com> Content-Language: en-US From: Luis Machado In-Reply-To: <87sfi30zgy.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LNXP265CA0049.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5d::13) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|DU2PR08MB10088:EE_ X-MS-Office365-Filtering-Correlation-Id: 2d3f017a-dffa-4ff8-d2dc-08dad1e38d09 NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3AvbpmKJbZjI3xodpoBlN/sGaRqHIBzjUfCVP5D2u2fwshtuxKO+bGLSWH3t3hoiIpl20lps5w2AQhgWXjvcHL5dwa8ZipkEYxMYRieEt7T/M4e5Iwx9TlqodFUCIMA39axwrw8yZQthmsovPZGhcXtMAUkyQEW0IG3LAto18LK3xqx4kH5uBsQFW4mME3pbOfo7bMTIcxJbH4yjVXDEf5fg9RCdp7sB4IYyizo9vYHAmXQQD01NQxO9YJFoTtdTYrNsoSqdU2QZBxnsTLIFl6WaB+1cScNvMuQeiPwE3UHQ5WABU2T32WxzU5GsIepq8W9+6AMH2OErX47v9ITZSF5ivE9IqhMRQ5aJcj6cVm3d5hmom3nlhVAulfnL+xBTLvv3KEP/xpNOb3ntrX8mfQKKTgPVUSklBdUhDGRrVO4MqdUCXs81SFMMsTDUyarIfgdDCTuEjOl/JlydcPJDCdAXUuxXnaFas9fEbMULKL3cYmwvQZAluumMup0Fxvkfa1eNhEmhh0vzatw8jJRqoPMR26wz9CFHJdAzCe2d086rRC4x5iYkAujnxID3a676DEzQlKWLtwWACN47tEGC7WOZKIeDMNaQx8CKwJbywJqzrx0wOiqbf8ADnRruYgVzFuuPlkgWxaxs1xHm+iEgYLHM5qqvNydNWiVrg2RmdijgZ1CH0KbCISDgGpVtjAGF7/wCWO+1JIVpX1LWtl5kPCg2xiQrgj5ix9pTCEpqPEuk/FEbLdF1Y6kb6l5biuoJ X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB3919.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230022)(4636009)(136003)(39860400002)(366004)(346002)(376002)(396003)(451199015)(2616005)(31686004)(2906002)(83380400001)(26005)(38100700002)(66556008)(966005)(66946007)(41300700001)(66476007)(53546011)(36756003)(6506007)(6486002)(6666004)(478600001)(6512007)(8676002)(8936002)(5660300002)(186003)(31696002)(316002)(86362001)(44832011)(110136005)(30864003)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bEs3dVI3QldrK2FaK1RBM1FsYnJFTDVrVU5za0lwYnpGV0VPUjFaYWx6bkJ2?= =?utf-8?B?TGtXbHA5TUh2ZkZXOTlTMjFWd2JoTHE3SmttOEt1MDF1TXRPWHRvbmd0RkxS?= =?utf-8?B?Q2tMd2c3UytXVjRFcC9CYmhhbFlzZG84YXlGa2NOY0lLQkd4T1RKd2RWZkd4?= =?utf-8?B?cEFyNDl6S2Jod2NHS3FscmExbGYzK09mOXlENGl0ZWxOOWkzR1l2OFljU0lk?= =?utf-8?B?RTAxck9BTzFYeVNyMlY5dUtGclFHdVBJZFdKUXh2MUtxM29tM0NlNFJOOUg1?= =?utf-8?B?cFF6RFNWUlNTa2c4N0t4WXNydmgwNUxTVU85cmRSYjdlVjd6ZUh6MGJXQW9r?= =?utf-8?B?ZTlyL0EvbUJXVVFmTHZQZExrYTNZTHJwZnU1UkVCUGp4VHlKRkp1NmZhaTBW?= =?utf-8?B?YjNZaHlkaUtzYktKbkVaODVmS3l4SjE1UWVWYWhYcFRDWHVZVFB2WjVJbFR0?= =?utf-8?B?VitXdHZjQ2FjN05GWlhOTENuMU1tcktDd2crbjZZeWdTVFhtWWozSG1RcHY2?= =?utf-8?B?SUVmUlE3UFMzNzVORUMzTEJzREo5VnJGZko0MXZ5NlhobWszQTdHVmZqcUJy?= =?utf-8?B?U1BnYW0yNm4yN1FlTFZQRlBHczVpcVAvOXlmaW1CK0Z0czF5dy93aTJGbmNk?= =?utf-8?B?YmVTd3dRdWFXNkFHMkpXa0hwRFJ5UEpjd1MzYThXV2QrekVVK1hjSzUrRWdB?= =?utf-8?B?YTd6TVU4MkFmdkRKMEIvbEd0eFVUN2ZOSzZtcTNXcFR1M01GQmVtNEt5L0pT?= =?utf-8?B?SXhicEYwbUg5UGpZSlFQU0Vkd0RQT3JWM1dMZytXcHRMeWIvdUcydTQyQ1BE?= =?utf-8?B?bWhQUGRNbzQ1KzNHMFZ4OG0wSXUyNlIxYVNoSUY2ZkcrRVB4SEpPWUo1VnZu?= =?utf-8?B?UEZZdmNwcklrRnZLOGk4dTFWY2RMZlpkbkVCSE92K2p2b1RkU1RiS05Za2VI?= =?utf-8?B?TWFGVzZiK25zazBYNU5lUXlFLzE5TGdMTkN2aWQrc2VnZnIvRVdCckNCejRR?= =?utf-8?B?bGhMWFlIUk82NGJRN0dVQ2duamtLazNIYndoSDBLUWNZM1JlcVB2SnlYdEdS?= =?utf-8?B?UjJIQ0VETkFqQ1hLMkZ6aGIyR1BPRXQwcXJKRTdDTW5OOXZ3UmhxeEVOcmtG?= =?utf-8?B?VEhiMW5rZ0h5ck9EaVZOc1BmcDBiV3VLR1g5UTVXQWpoSk56TWFBQWllYStX?= =?utf-8?B?WUJsM3VIclhkQVRuYUpjUTVnVm0vdUVhTHJlZmF0YWdwT29DejI1ZWUvbENh?= =?utf-8?B?MHBjU0dpUHJUelY1QmducktpajhNQWxUYUFxQlM1d2djYm1KRHR1UURZN3ZF?= =?utf-8?B?aVFTMHdTZmN3QjJpUUVQcXpaVkZVd044dFVER0UyUkxEZHlhNjJwcjdQQzZw?= =?utf-8?B?RXdkZlgzZVphTzJSeTJRQ3pDU2NZMGxEbmpia3FWQUJ2QnM5ZXpqaVhZK2Jp?= =?utf-8?B?Y3o2SnZ6amZLaWZpcFhaWlIrcXp0Q2xWSkppMTBoeFZXbWxuWDFCd0lNZ2d6?= =?utf-8?B?d2RaSjdQdDZMOGdVRzJXSmJOaGJXbVVGK3o3SUNxRnJGTStvMG95VEZJZER5?= =?utf-8?B?ekY3Uko3QTFXU05odnZaZzgxRm1HSERYand3cTY5dnkxa2NQR25BNzFGQjFs?= =?utf-8?B?V2dyU1NQeXFaQ3dJME9CZkpSMTh1TS9Oa3FMTWVmUGpkc2pFNE9rZ2srS0g0?= =?utf-8?B?a2RYcHVOdFFYUmNjcmlwUjNhbEFOUWd1YlpJaStnT2EwMExwS2I5ekdHZldu?= =?utf-8?B?OUQ0Vit0L01PQXlZYmZpcHN3N2ZtN1owWERHcEJ4Um1DZGN1NWl0bXpKM0tJ?= =?utf-8?B?amxMOUFqN1d5c0hxNktPZmN3cnJ6VWFQazFhY1o1a0FxRUxCaHdpTGNwRXJB?= =?utf-8?B?a3pxeDlscGFKSTdOK0hOaFcwUzBrd0x3SElLZEZFZ01Vc0kwNlEyR1JXZ3NG?= =?utf-8?B?U3dpNUR1bSswOVJHSE55MHBLL2p4U1RtemJ3NzVxeGM2ZW5rbU9HWHJpU1pz?= =?utf-8?B?NE1RdFF5V2NIek05ZHdaU3g1R2pveVU0V01PTXRJejRZQzZaaWlCQVNQU0dS?= =?utf-8?B?bWlNMzh2THY3Vk9FV20wU3hyUWhINmx1RitoUlg2dkdQUC8vc0Fhb2trdXFs?= =?utf-8?Q?yA2QTdqf6BPwjiNsiTCQTws1X?= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2d3f017a-dffa-4ff8-d2dc-08dad1e38d09 X-MS-Exchange-CrossTenant-AuthSource: VI1PR08MB3919.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Nov 2022 08:27:28.2077 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: dXAfQ6xvTWjte7xZNPGw7LCWjZcV646xbYV1mIzJMOBy0Rkci/6jNS74riZ2hkm+4hkfma/kgZ3SMhjoI3La8w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU2PR08MB10088 X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FORGED_SPF_HELO,GIT_PATCH_0,KAM_DMARC_NONE,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,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 List-Id: Hi Andrew, This seems to have broken armhf on Ubuntu 22.04. https://builder.sourceware.org/buildbot/#/builders/169/builds/1163 On 11/28/22 17:18, Andrew Burgess via Gdb-patches wrote: > > Thanks you all for your review feedback. > > I've now pushed this version of the patch (inc Pedro's suggested typo > fix). > > Thanks, > Andrew > > > Andrew Burgess writes: > >> Simon Marchi writes: >> >>> On 11/22/22 10:09, Andrew Burgess via Gdb-patches wrote: >>>> From glibc 2.35 and later, the "map_failed" stap probe is no longer >>>> included in glibc. The removal of the probe looks like an accident, >>>> but it was caused by a glibc commit which meant that the "map_failed" >>>> probe could no longer be reached; the compiler than helpfully >>>> optimised out the probe. >>>> >>>> In GDB, in solib-svr4.c, we have a list of probes that we look for >>>> related to the shared library loading detection. If any of these >>>> probes are missing then GDB will fall back to the non-probe based >>>> mechanism for detecting shared library loading. The "map_failed" >>>> probe is include in the list of required probes. >>>> >>>> This means that on glibc 2.35 (or later) systems, GDB is going to >>>> always fall back to the non-probes based mechanism for detecting >>>> shared library loading. >>>> >>>> I raised a glibc bug to discuss this issue: >>>> >>>> https://sourceware.org/bugzilla/show_bug.cgi?id=29818 >>>> >>>> But, whatever the ultimate decision from the glibc team, given there >>>> are version of glibc in the wild without the "map_failed" probe, we >>>> probably should update GDB to handle this situation. >>>> >>>> The "map_failed" probe is already a little strange, very early >>>> versions of glibc didn't include this probe, so, in some cases, if >>>> this probe is missing GDB is happy to ignore it. In this commit I >>>> just expand this logic to make the "map_failed" probe fully optional. >>>> >>>> With this commit in place, then, when using a glibc 2.35 or later >>>> system, GDB will once again use the stap probes for shared library >>>> detection. >>>> --- >>>> gdb/solib-svr4.c | 13 +++++++++---- >>>> 1 file changed, 9 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c >>>> index 6acaf87960b..87cd06f251a 100644 >>>> --- a/gdb/solib-svr4.c >>>> +++ b/gdb/solib-svr4.c >>>> @@ -2205,10 +2205,15 @@ svr4_find_and_create_probe_breakpoints (svr4_info *info, >>>> >>>> probes[i] = find_probes_in_objfile (os->objfile, "rtld", name); >>>> >>>> - /* The "map_failed" probe did not exist in early >>>> - versions of the probes code in which the probes' >>>> - names were prefixed with "rtld_". */ >>>> - if (with_prefix && streq (name, "rtld_map_failed")) >>>> + /* The "map_failed" probe did not exist in early versions of the >>>> + probes code in which the probes' names were prefixed with >>>> + "rtld_". >>>> + >>>> + Additionally, the "map_failed" probe was accidentally removed >>>> + from glibc 2.35 and later, when changes in glibc meant the probe >>>> + could no longer be reached. In this case the probe name doesn't >>>> + have the "rtld_" prefix. */ >>>> + if (streq (probe_info[i].name, "map_failed")) >>>> continue; >>>> >>>> /* Ensure at least one probe for the current name was found. */ >>>> >>>> base-commit: 84f9fbe90e5429adb9dee68f04f44c92fa9e2345 >>>> -- >>>> 2.25.4 >>> >>> Hi, >>> >>> I looked at this separately, and this was one of the fixes I considered. >>> >>> Another option was to make GDB not give up on the probes interface if >>> failing to look up a probe whose action is DO_NOTHING. Probes with that >>> action are not used by GDB for solib bookkeeping, but can be used to >>> stop on solib events, with "set stop-on-solib-events". I was just >>> worried if there was some cases where a probe would be missing, but the >>> corresponding event could be caught if using the original interface. In >>> that case, using the probes interface would be a regression. But it's >>> probably not worth wondering about. If that happens it's just a bug >>> that needs to be fixed. In the case we are looking at, if the >>> map_failed probe gets optimized out, then surely the corresponding call >>> to the r_brk function would also be optimized out. >> >> I also considered just ignoring any probe was (a) missing, and (b) had a >> DO_NOTHING action. The reason I didn't post this patch was because, at >> the time, my thinking was: if we don't care about any probe with a >> DO_NOTHING action, why even look for those probes, why not just remove >> them from the list? >> >> I think you've (partially) convinced me that the user might be >> interested in seeing a stop at these probes even if GDB's action is >> DO_NOTHING. >> >> I say partially above because GDB doesn't really do anything to tell the >> user which probe we stopped at, e.g. was is "init_start", "map_start", >> "map_failed", etc. The user might be able to figure it out from the >> backtrace, but I still think it's not going to be trivial in all cases, >> e.g. "map_start" and "map_failed" are both located in the same function, >> so I think the user would need to lookup the probe address in the ELF, >> then compare that to the stop address. Not impossible, but, I suspect, >> the complexity is an indication that users are not doing this much. >> Thus, I suspect, in reality, nobody really cares about the DO_NOTHING >> probes. >> >> However, I think there is enough of a justification there for keeping >> the probes in the list, and just skipping any DO_NOTHING probes that >> don't exist. >> >> Below then, is an alternative patch. I don't have a strong preference >> between this one, and the original[1], but I thought I'd post this for >> discussion. If this is preferred then I can just merge this. >> >> [1] I'll also post an update to the original patch shortly that >> addresses Lancelot's feedback. >> >> Thanks, >> Andrew >> >> --- >> >> commit 11be1f25f446e68c23d0709cde46e32ff24b7eb9 >> Author: Andrew Burgess >> Date: Tue Nov 22 12:45:56 2022 +0000 >> >> gdb: relax requirement for the map_failed stap probe to be present >> >> From glibc 2.35 and later, the "map_failed" stap probe is no longer >> included in glibc. The removal of the probe looks like an accident, >> but it was caused by a glibc commit which meant that the "map_failed" >> probe could no longer be reached; the compiler than helpfully >> optimised out the probe. >> >> In GDB, in solib-svr4.c, we have a list of probes that we look for >> related to the shared library loading detection. If any of these >> probes are missing then GDB will fall back to the non-probe based >> mechanism for detecting shared library loading. The "map_failed" >> probe is include in the list of required probes. >> >> This means that on glibc 2.35 (or later) systems, GDB is going to >> always fall back to the non-probes based mechanism for detecting >> shared library loading. >> >> I raised a glibc bug to discuss this issue: >> >> https://sourceware.org/bugzilla/show_bug.cgi?id=29818 >> >> But, whatever the ultimate decision from the glibc team, given there >> are version of glibc in the wild without the "map_failed" probe, we >> probably should update GDB to handle this situation. >> >> The "map_failed" probe is already a little strange, very early >> versions of glibc didn't include this probe, so, in some cases, if >> this probe is missing GDB is happy to ignore it. This is fine, the >> action associated with this probe inside GDB is DO_NOTHING, this means >> the probe isn't actually required in order for GDB to correctly detect >> the loading of shared libraries. >> >> In this commit I propose changing the rules so that any probe whose >> action is DO_NOTHING, is optional. >> >> There is one possible downside to this change, and that concerns 'set >> stop-on-solib-events on'. If a probe is removed from glibc, but the >> old style breakpoint based mechanism is still in place within glibc >> for that same event, then GDB will stop when using the old style >> non-probe based mechanism, but not when using the probes based >> mechanism. >> >> For the map_failed case this is not a problem, both the map_failed >> probe, and the call to the old style breakpoint location were >> optimised out, and so neither event (probes based, or breakpoint >> based) will trigger. This would only become an issue if glibc removed >> a probe, but left the breakpoint in place (this would almost certainly >> be a bug in glibc). >> >> For now, I'm proposing that we just don't worry about this. Because >> some probes have actions that are not DO_NOTHING, then we know the >> user will always seem _some_ stops when a shared library is >> loaded/unloaded, and (I'm guessing), in most cases, that's all they >> care about. I figure when someone complains then we can figure out >> what the right solution is then. >> >> With this commit in place, then, when using a glibc 2.35 or later >> system, GDB will once again use the stap probes for shared library >> detection. >> >> diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c >> index 6acaf87960b..10e446af908 100644 >> --- a/gdb/solib-svr4.c >> +++ b/gdb/solib-svr4.c >> @@ -2205,15 +2205,34 @@ svr4_find_and_create_probe_breakpoints (svr4_info *info, >> >> probes[i] = find_probes_in_objfile (os->objfile, "rtld", name); >> >> - /* The "map_failed" probe did not exist in early >> - versions of the probes code in which the probes' >> - names were prefixed with "rtld_". */ >> - if (with_prefix && streq (name, "rtld_map_failed")) >> - continue; >> - >> /* Ensure at least one probe for the current name was found. */ >> if (probes[i].empty ()) >> - return false; >> + { >> + /* The "map_failed" probe did not exist in early versions of the >> + probes code in which the probes' names were prefixed with >> + "rtld_". >> + >> + Additionally, the "map_failed" probe was accidentally removed >> + from glibc 2.35 and later, when changes in glibc meant the >> + probe could no longer be reached, and the compiler optimized >> + the probe away. In this case the probe name doesn't have the >> + "rtld_" prefix. >> + >> + To handle this, and give GDB as much flexibility as possible, >> + we make the rule that, if a probe isn't required for the >> + correct operation of GDB (i.e. it's action is DO_NOTHING), >> + then we will still use the probes interface, even if that >> + probe is missing. >> + >> + The only (possible) downside of this is that, if the user has >> + 'set stop-on-solib-events on' in effect, then they might get >> + fewer events using the probes interface than with the classic >> + non-probes interface. */ >> + if (prove_info[i].action == DO_NOTHING) >> + continue; >> + else >> + return false; >> + } >> >> /* Ensure probe arguments can be evaluated. */ >> for (probe *p : probes[i]) >