From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR03-DBA-obe.outbound.protection.outlook.com (mail-dbaeur03on2052.outbound.protection.outlook.com [40.107.104.52]) by sourceware.org (Postfix) with ESMTPS id 34730382FC8F for ; Mon, 5 Dec 2022 10:27:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 34730382FC8F 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=DntQVk0AyhFTSWEMj7IhlBO7jcJEQRvaJlSIZOfAtpKCsgOWC9l9FEtG8ltn9T5/VxLK8fb5Ifb4pOtab+A9W9jaD0UBp7MN1XqJxJvdCaL0ZzPg7pw6WGavIYoVkAVPIKhWRUiW1p8z9ZI++ng1F8OTmH9uE4PHY7IluoUewCt991f32HAmgFdqz5hQ2cDW8jxc7lZDmk3LZgwyId62dabFVdTf00vgOnaotVSe/vpSObnpYSc/zXzG9XEEN9ZNlmTkPhhT7r8V8u7f1jTleVWXqOJSe8gIEm0YuK2i5cO0l4PjdmsJIns4nJ5cpRlZyvJ9oj5c8M7WbKuiznBkqw== 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=euWB4tA2s7efI2Eu/QVcjDus3zq4ETBHCjs3db4f0nQ=; b=gW6bC6ALRvcFmfBttUvznH9LSoDk4rMqaR7Q5DpkVXsfvJi9kzwdGKsbNIOxO1fUzeP3Vquh+Von7wZsEuAN9jtkodC7ZrZ1xEmhP/55BxjkoJ3lURvELTFsRtg2gveaovkgJ0KpArAO0hiKUYZeHliXSLg4QZM4zqD7Fi446AfC83SEVTdFGDWe9zWLIAe11j8tg8W22pR+p/xuAuTFz8uWVFYDuw/osHtTL64J47Uao5xiE6QfCnK740u6jCNB3YYy2mfHHansRGQvZnLrvMdskfxDx+VJN5NYpsIazFWXyvFcOVANGaS/+ySekjTbTF1USZayZ+N58o2KHDGIFA== 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=euWB4tA2s7efI2Eu/QVcjDus3zq4ETBHCjs3db4f0nQ=; b=bGtI8daEWeABrNCufGpHJ9otR5ttL2JBdl9UqrGxqqAX3as00rCMLaatHdpYmHWZlqT482z71vqrxXQZvuOFSJE5drwnA5iOTn3xqRE7b9OE+JMLoVsIiaaAI7Ltu6I/hfmxQITTcSDquH7/um0gDyzvbH/yE7PvBK5IOV3eVn4= 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 DBBPR08MB6154.eurprd08.prod.outlook.com (2603:10a6:10:1f4::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.11; Mon, 5 Dec 2022 10:27:47 +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.014; Mon, 5 Dec 2022 10:27:46 +0000 Message-ID: <9135877b-0e37-6fd2-8c69-e9d0376b75e7@arm.com> Date: Mon, 5 Dec 2022 10:27:45 +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> <610ebe6b-64d0-d0c9-f9da-9e1445d53d73@arm.com> <87mt8240w8.fsf@redhat.com> Content-Language: en-US From: Luis Machado In-Reply-To: <87mt8240w8.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO6P123CA0010.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:338::14) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|DBBPR08MB6154:EE_ X-MS-Office365-Filtering-Correlation-Id: 99f7e486-7f9d-4013-614e-08dad6ab5a02 NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: R+l8NHMlr+bkUtX3mn44tt5BnYL+eEyn+MKa4c1B+nIugb/we+qfdKiYB36P+DlkIr6ixzspLAPV5Otx9M1TfU8M/BhlhJ16tvR02sVX1+wIkArYVlC5w7jpBLHq/qam+iKR99TNx+htqNTEXYU82RMaIT7/uzx3oD9D5KjnsEHMGeXMggV8WdqNyetRIXuTvCiczKEH2FwRdWYBRc0vzlx/eYNZlSpZj7eHC6Nuei4QdLwoQ/O9TK1p52y8NBxqm4kpox7EqDnHajsbwyTwHKoHgzcv1xuG0Hp/x02eJl0TsNqjo9HR23XK9+IhDMFiklUwPImi9FBR3HWeXLXRTwguCzRgtEzbQA3HeefEfLT5JJSfcL1H8qkx4U0PIcJ67aqE6/Fvywn0E96hZ4gr7+FFpf479jqLiutsic1gnfQgziDSDeM4yqsysV3JFH/PN4HICO43716UdcYWadxxnA8nOaBR4W++/KyFbzapPev6C03LTcHD1Pp2FQP2wFLSu5HqxqKDX2ZiBrFuhKopO1PRRcF/wkDle/Air9GUUc30O3YyGBOrTGo721keBsWneXTUsWogzAF3EL6qZ/S0qfVEOTUNuhCY5/YP+za/Bjc5S7DOXhuyA8o6A/EK27yNLvXtCmfHT4MJ3NGrtBYahYXVF7k6n5/DYIwM5Hd1cGCD7B3H5Ktu5aQqLKO7pcVvRzo2tDkZLMQXQvevsqHZrKMOUqIwiWHXc2Es1jFll3brtIAP20lWBkeRnHfswxov 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)(396003)(376002)(39860400002)(136003)(366004)(346002)(451199015)(31686004)(36756003)(86362001)(2906002)(83380400001)(38100700002)(186003)(8936002)(30864003)(41300700001)(5660300002)(44832011)(31696002)(2616005)(316002)(8676002)(110136005)(6486002)(66556008)(66946007)(66476007)(478600001)(53546011)(6512007)(6506007)(966005)(26005)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OVNNT2lsU0Jya2RJYzZnTlluUzloY0RTbVd3YzF3aFExSkU2amxQVlYrdWpo?= =?utf-8?B?cU1ZRmJOeFBiMWoxZTBPMnR6Y05ic2wvUURNd1kyei9ndjVDWktNR2RSVitC?= =?utf-8?B?Wlc3NGFtV2JIMmtnYTdFWDlOSFNiM2hvN2xxMktsNHF4a3pkN0NzVms2OS9x?= =?utf-8?B?VThMVk0ydXpPcS9RSFJ2TldlMUNMQ0VOVDJUVUtLbEdOejFheFFoWEdPT0Zn?= =?utf-8?B?R0RTNURwQkg5UmJEci8vd1FpOU5pVkc5dXFiTW56MS9JRGlnY2lvWGJTSjN1?= =?utf-8?B?eEpMdmpLME5ydThzRzl6MWd6REdmV0pWcTV2VW5GenJRNzlRNTVZZDN5dERO?= =?utf-8?B?VlZXWnRuTHBtVDFGY2VsZzFZRzFNU1ZpcnRSMjdTZjUrNnEvSGhzZXFMVnc0?= =?utf-8?B?Y0ZwSHVpU3VhdzNuMXJadDg0V0t5YWw2TVRzU0R1UHd1VnJ5UWpxTXd2dEZL?= =?utf-8?B?Z3VOMnVHR0hDcGJFR0dBdXNPSTQ3K3Q4WFVtTmtvVExOZmJVTitOWVEvVzlW?= =?utf-8?B?RGdZV0ttWHM5OWM5V25lczY3VEFZVUtZaExPQnRBYjE2aXg4Wjl4UTRTUmR2?= =?utf-8?B?RkJjUzFVOGd2RkdXMklFMkVHRjM4Y0YyRGdNbFhGKzR2bnhGaGJLYmE4cm5H?= =?utf-8?B?REcvMlQ1ajhWdG5PSWdadTBJdkx1S3dYdEdDK2UxUnk1clFLRTlHellvUjd2?= =?utf-8?B?K0pCSEF0cmJ2QTl5VmxNWnlsTVNHQitrdEJ2aDdVaEQ0NklYY3IzSnBJWWdE?= =?utf-8?B?MXRKUjU3R05NNkxrMXVDb3g0MVMzWERtZjQ4U1ovWFFXZTRnbXRlTlgrSGhC?= =?utf-8?B?Tk1paWRaVWxGRy9JeWJqS0pCSUtGRi9UazJsMGZqdGJXWE5sUVMzNDRkRStJ?= =?utf-8?B?NFBoYzhVbnpwU3FFSysvbEthb3Ntd2VxbmUvS1UwVHl2ZkRlc0c1QkVLclhv?= =?utf-8?B?enM5UXozY2dodVlkUHhwdDVIZWRlSzg0Y0w5UnBmOE41NUpYSzlZbHpsRnRR?= =?utf-8?B?NWV4Rmh6UmdmbVhpaTJ1NmdMNnIvRk90S204TE5ZV1pFK0FuR1YxSC9SQldE?= =?utf-8?B?ayt0OENVM3BFd2YrSmg1dzB3OGpPRzBCWFZJOTVEeUJqQW1QTzZqSGJkWmY0?= =?utf-8?B?K3RLYnJ6dkE0N25zbGNOMkt0cytWMlcyeUdpQnhJRXFlWGtkNEQ1dDY3TTBM?= =?utf-8?B?ay9mY0Y0dnd4NEQ5Q1R1eklocU9TTjA3VWg4VmNUNXVKVExiaW9wYnVyN1RM?= =?utf-8?B?N0ZSUG1ZcTdoOHFaL000QUtkYW01UDNDY0VJRE1oNFFLK0J3L2JYK3VJRit6?= =?utf-8?B?NW1wejFTWWhDVEtOam9UNjJuQk5sZTRSU2tyVkp5OVFyNEJyUWFRWEtqV2VX?= =?utf-8?B?U25FK2VMQ0NzdU04Q1VzVllqL0M1WEROUTZvU3dCSXpOU1ZFcnZ2bG1IUmw0?= =?utf-8?B?enkwa25Xa2lNUSswL2xGaU56b2J1RmNXQ2trRXRwSW44L0c1eEZlNU44c3hN?= =?utf-8?B?WExxSmdmZjJTOVNpNkR0SjVhaFNTNm5HcXZyTEM5N3RXYkgwRDBvTndxejNS?= =?utf-8?B?NlBtWTdxOGFrT1NoRlNJdVJXcXRuREs5U2YxWEQxWnBwMURQWVNvbTVyNG5o?= =?utf-8?B?bEdyelVYelAyUTlQaGxPZXBLeTdtM1RFRThSVlFnYmptMi9saWIzMnpLVWdX?= =?utf-8?B?dkF6dnk4eVY3aUsxbmcrREpXTkZUVWsvNzJDZVFEL3BDQmxpelA1Q2I4WnFR?= =?utf-8?B?RStTT1ZjZlNhWVlvOXNZdUloK2wwMlZvZ0hXRTBTMjM4YUFvNm1vSWJkbmpQ?= =?utf-8?B?RXBDT1dJUDdjUEYzU081cGFicHdnWEdYNmNwTyt2L294d0diVWJERUN2em8r?= =?utf-8?B?SG1ra1VVb1dyWnRRUlRBL3ZuOUhoSUJYWjU0Q2lYeDhlcFVvdmIrNUF2OFhX?= =?utf-8?B?UzV4ZGtGMDFJQVNyMUd2ajV4NU4zVHhPTVVnTUdwajNQeGVmVWlKZXlwZG5P?= =?utf-8?B?dThNWWxnTTdobUd5aUJIZktCNzBuRmducWd3ZzNEOXNvaSttRFU1RFJnRUky?= =?utf-8?B?eXo5V2pYQjZOak5qTll0YmNOTzBEZ0I0VmJYNjl0N0h4TnMyakNFODVPNmpV?= =?utf-8?Q?9ryQf0ZddTydKHRMk7CtCRf7J?= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 99f7e486-7f9d-4013-614e-08dad6ab5a02 X-MS-Exchange-CrossTenant-AuthSource: VI1PR08MB3919.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2022 10:27:46.5453 (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: WCCdmeqjN1B/Kv2X5BGlmDxV58vs30xlXWrOuETUh/3FOrzr58bI6YjtQWiPVrmH9NPt7bXm8rMfG5gOj7ucRA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB6154 X-Spam-Status: No, score=-10.4 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,GIT_PATCH_0,KAM_DMARC_NONE,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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 List-Id: On 12/5/22 10:09, Andrew Burgess wrote: > Luis Machado writes: > >> On 11/29/22 08:27, Luis Machado wrote: >>> Hi Andrew, >>> >>> This seems to have broken armhf on Ubuntu 22.04. >>> >>> https://builder.sourceware.org/buildbot/#/builders/169/builds/1163 >>> >> >> I haven't investigated this. I only spotted it in the sourceware buildbot page. But I'd guess it is something to do >> with thumb mode detection early in the startup. >> >> Ubuntu has moved to not stripping ld.so for armhf because the probe mechanism is not capable of conveying the thumb mode >> information, so gdb has to rely on symbols instead. If the changes have touched this fragile area, it may have broken the >> delicate balance. > > I somehow missed this last week. I'll take a look today. > > Sorry for the breakage. No problem. For the record, I haven't managed to reproduce this on my Ubuntu 20.04/22.04 setup. I'll have to give it a try on the buildbot machine. Just a heads-up in case this doesn't reproduce for you either. > > Andrew > > >> >> >>> 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]) >>>> >>> >