From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id V4nSJZ0TpGofRAAAWB0awg (envelope-from ) for ; Fri, 11 Sep 2026 10:43:41 -0400 Authentication-Results: simark.ca; dkim=fail reason="signature verification failed" (768-bit key; unprotected) header.d=tromey.com header.i=@tromey.com header.a=rsa-sha256 header.s=default header.b=xxmh6qye; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 87EF91E091; Fri, 11 Sep 2026 10:43:41 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_INVALID,DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id B11FE1E091 for ; Fri, 11 Sep 2026 10:43:40 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9660648A080C for ; Fri, 11 Sep 2026 14:43:38 +0000 (GMT) Received: from omta36.uswest2.a.cloudfilter.net (omta36.uswest2.a.cloudfilter.net [35.89.44.35]) by sourceware.org (Postfix) with ESMTPS id 3866D4BB8F77 for ; Fri, 11 Sep 2026 14:43:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3866D4BB8F77 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3866D4BB8F77 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=35.89.44.35 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789137802; cv=none; b=Xays3qCkS7CYE0aua6bc+gZ+sG6Xx2hKDJunFEfMRCwv+BcwzqhpIQ+8cMoof28aYBbYBFba9qlVvU2h3r01zOMt80qIpKEqikmGOUV8OEP1ksZ7JIh0ky+0pGGaAL1shnZ6ZGJJTshc+6+b7RJDDzPNCNI0LCEjwu8L8W39cMk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789137802; c=relaxed/simple; bh=TH/9s6jJyzwuIbxxT0xz4WewmhMRiQmw3RGyNEu+umc=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=lu25MNXk8Ty3YOqZNVVieENlAnnoPAuqDog4dwYlNqd71Q0Ab1+GI/iB6oyBGm2qI6PKGtFYD+y53mgO7VhHMFHV2KWEmBaS7BQxB9Khv//M1tJMqsOtiueTCD2m6d6CWf8TnaqL2aWuQrw927t0KSzP+aeELItHYz0SefxS8Xc= ARC-Authentication-Results: i=1; sourceware.org Received: from eig-obgw-6001b.ext.cloudfilter.net ([10.0.30.143]) by cmsmtp with ESMTPS id 4uUAxhjcAusRS52TDx0Ors; Fri, 11 Sep 2026 14:43:15 +0000 Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTPS id 52SwxMGrF9tXG52Sxx1whA; Fri, 11 Sep 2026 14:42:59 +0000 X-Authority-Analysis: v=2.4 cv=KK1aDEFo c=1 sm=1 tr=0 ts=6aa41383 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=VdqzKS8jKosA:10 a=ItBw4LHWJt0A:10 a=CCpqsmhAAAAA:8 a=uMHXFainsdreTxTr-zsA:9 a=ul9cdbp4aOFLsgKbc677:22 a=DCx65vhANUyCzuf5D8fC:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Unsubscribe-Post: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ooiHbmH5PjSJTymUj0/shOtyM8negZnlhOGfyatypss=; b=xxmh6qyeWbnCAO8maiRYd1Sgfv CP43HRci9vz0XoNmya7/V9oCU8gXrOAQOEuuE1VRtMPzlMYMQRg0YHOr26UEE0xiMHBAhF8ppY69U B4lBluTA4v5dkvTwzKzzFtqxM; Received: from 97-122-117-2.hlrn.qwest.net ([97.122.117.2]:46936 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.100) (envelope-from ) id 1x52Sw-00000001vUB-2AJs; Fri, 11 Sep 2026 08:42:58 -0600 From: Tom Tromey To: Tom de Vries Cc: Andrew Burgess , gdb-patches@sourceware.org, Abhay Kandpal , Tom Tromey Subject: Re: [PATCH 2/2] gdb: catch some exceptions in find_function_in_inferior In-Reply-To: <5424362d-623e-459a-b06f-a0d9530c83dc@suse.de> (Tom de Vries's message of "Fri, 11 Sep 2026 13:07:36 +0200") References: <5424362d-623e-459a-b06f-a0d9530c83dc@suse.de> X-Attribution: Tom Date: Fri, 11 Sep 2026 08:42:57 -0600 Message-ID: <87ld97zw5q.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 97.122.117.2 X-Source-L: No X-Exim-ID: 1x52Sw-00000001vUB-2AJs X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 97-122-117-2.hlrn.qwest.net (bapiya) [97.122.117.2]:46936 X-Source-Auth: tom+tromey.com X-Email-Count: 7 X-Org: HG=bhshared;ORG=bluehost; X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-CMAE-Envelope: MS4xfOz2o7PYT8VS1L87XQ4mG65c3+qnmnxh118F0XbshTg9YQLRLpTcGQzosc1T+A9m8LcXzR//7SXxBvrvyVc7WmWThJ936yw+5laiKuyM3L3C4CDvFtcy EThwNM9RZ4mhGxL3yuZkMEFVfes/xnqcsM0GCH2e4y6O+v52n6WqED6d7EYsR/bSs8O8GggXgc/MeqdhksFmpsWlTeDqczwYqrs= X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org >>>>> "Tom" == Tom de Vries writes: Tom> The first thing I found was that the alias system.crtl.malloc == Tom> malloc is present due to extra debug info in the executable. FWIW, it Tom> comes from ./gcc/ada/libgnat/s-crtl.ads: Tom> ... Tom> function malloc (Size : size_t) return System.Address; Tom> pragma Import (C, malloc, "malloc"); Tom> ... FWIW doing name lookups in Ada is weird, because Ada defaults to wild matching. If you want to just find the C malloc, you have to look for "". So, if the code is going via any language-specific lookup route (I didn't dig in but it probably is), then you can easily find the wrong function. It would be nice to fix this, but it's complicated. Alternatively some kind of language-neutral or "force it to use C" approach could be implemented. Tom> In case the c function Tom> is represented in the debug info, the alias target is found. Tom> Otherwise, not. This seems incorrect to me, so I filed a PR for this Tom> ( https://sourceware.org/bugzilla/show_bug.cgi?id=34627 ). I commented in the bug, but this is unavoidable. The error is thrown because gdb wants to find a function block -- but if the alias target doesn't have debug info, no such block is available. Tom> Looking at ada_alias_get_block_value, ISTM that using Tom> lookup_global_symbol means that it doesn't look beyond the exec Tom> containing the alias. So in conclusion, I'd say the debug information Tom> is present, but ignored. This part seems strange in that lookup_global_symbol should search all objfiles. But I wonder if instead it's finding the wrong symbol due to wild matching. Anyway I suspect something else weird is going on. Tom> This might be due to a gdb bug, so I filed a PR ( Tom> https://sourceware.org/bugzilla/show_bug.cgi?id=34628 ). Tom