From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id /g2BGCEFn2pw+TQAWB0awg (envelope-from ) for ; Mon, 07 Sep 2026 14:40:33 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=fhdDIwVf; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 4D8A71E09E; Mon, 07 Sep 2026 14:40:33 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,HTML_MESSAGE,MAILING_LIST_MULTI, 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 B67F21E033 for ; Mon, 07 Sep 2026 14:40:31 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BE05D48F8E13 for ; Mon, 7 Sep 2026 18:40:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BE05D48F8E13 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=fhdDIwVf Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 1A59C49B0B91 for ; Mon, 7 Sep 2026 18:40:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1A59C49B0B91 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1A59C49B0B91 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=148.163.158.5 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1788806402; cv=none; b=IA+3OHHffy9CgpWyJugI5Hx7vcfoZ268sM2m1bV8G3xXt++XcLltJ/bTWIzYCuiiYJ07DQAxpF/jgBe4j+gp/F2Id0dRT4M9mRUnNjYQxE3qKa9EnDAjZXCkywe1twsoL/TTpygZUUZ5XqxAbOy+UoZKdJVEpZsHdld60WWpjDc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1788806402; c=relaxed/simple; bh=3chDYrvgZdEE1bwSIysuRCiB1C7FWz9PL9iVgBPIcxw=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=l2BfM0C5b6DWTtMd3605GCGvHJPRl7UTPYnzxLjZIkLDFmGkzUWeeI5P9VeVumuCWqQYfZpL+LnBbnyzozVDOAvtzgyRpxrrzCMRnHvKPz2Iqu+JqcQ2/cyHSfoeJXWaguyevpEFeS7vESWS5WkfMCjZNh/kPINAuw005C5Zc2I= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=fhdDIwVf DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1A59C49B0B91 Received: from pps.filterd (m0356516.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 687HVe8i2464209; Mon, 7 Sep 2026 18:39:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=pp1; bh=S2sd9WfuYobu0JHQPusvn5cSmunw6q 5F/NoSpyBGtcc=; b=fhdDIwVfRQILzrEXJMfkMCfZwO1KbYJgOvyHvAixGfiysN YAeEGmyFlsCNpPNP2ij3vTVDht9lTWLY1Z+mHDr1Kvr5uVFdgpw8Vd3XpJ6UMkTe Za8Sj42C4TMaUT9oTfcj3RKl5JTT9/ym3LTB7mik7lPNI2k55w5hK4nqAbrEJVKH B/G/6pHSYdnmngfJQ1WPLZgFy1JckcUTNZELFCkbkY7FJBn9OPWJ5VRUmIipTkvw SBXGsVky/BfHU0H8JUbbjwn8Z8Rq97Ok4ZhfUKyhsLoAU76FYJj949iQXhKbT5zx LnyvdcSB6UEmp1Sxr7UtqeU2fuPXhyWlO9djRvbg== Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4ggbj8253q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Sep 2026 18:39:58 +0000 (GMT) Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 687IQJr7026104; Mon, 7 Sep 2026 18:39:58 GMT Received: from smtprelay04.wdc07v.mail.ibm.com ([172.16.1.71]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 4gh03y77n7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Sep 2026 18:39:58 +0000 (GMT) Received: from smtpav04.dal12v.mail.ibm.com (smtpav04.dal12v.mail.ibm.com [10.241.53.103]) by smtprelay04.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 687Idv2Y25362944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 7 Sep 2026 18:39:57 GMT Received: from smtpav04.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 137F05805A; Mon, 7 Sep 2026 18:39:57 +0000 (GMT) Received: from smtpav04.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F1E4958056; Mon, 7 Sep 2026 18:39:54 +0000 (GMT) Received: from [9.124.223.77] (unknown [9.124.223.77]) by smtpav04.dal12v.mail.ibm.com (Postfix) with ESMTP; Mon, 7 Sep 2026 18:39:54 +0000 (GMT) Content-Type: multipart/alternative; boundary="------------zJ1LFdQXZ47D9PGcRr6DbRsm" Message-ID: <5b67f287-42f8-4ac9-956b-b0a1b1527009@linux.ibm.com> Date: Tue, 8 Sep 2026 00:09:52 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb: fix incorrect search domain in find_function_in_inferior To: Andrew Burgess , gdb-patches@sourceware.org References: From: Abhay Kandpal Content-Language: en-GB In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-GUID: PiD9kfkTMajGdkW63O9h9D1W3a0vCVNo X-Proofpoint-ORIG-GUID: PiD9kfkTMajGdkW63O9h9D1W3a0vCVNo X-Authority-Analysis: v=2.4 cv=RNCD2Yi+ c=1 sm=1 tr=0 ts=6a9f04ff cx=c_pps a=aDMHemPKRhS1OARIsFnwRA==:117 a=aDMHemPKRhS1OARIsFnwRA==:17 a=VdqzKS8jKosA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=Y2IxJ9c9Rs8Kov3niI8_:22 a=r77TgQKjGQsHNAKrUKIA:9 a=zpSroc4RaD-uSNFUPbUA:9 a=QEXdDO2ut3YA:10 a=20KFwNOVAAAA:8 a=O4Vf_GqLEebnUakwjv0A:9 a=z4W7JxtACbkSwEuB:21 a=_W_S_7VecoQA:10 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTA3MDIwNiBTYWx0ZWRfXwXhYMNSSazXb A+OPZrrYV+3t3zVpkJ5Hz75MWwyShQru6VV2bX9ywvLcjiMBpc45PC9hUg0l2FEUY8uZcbBZAo/ 7x9liBlLXZXlHLRm4hawWpKi2OlaNFo= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTA3MDIwNiBTYWx0ZWRfX8NCtHAoIR/XP PAFhS7CHlp14gXHWzlj6+KaAOrcvuRLy9Nd5T+Nqlw6tu5NAar4PHwkyWgtoyZtONVm0LNW5M5B t3316fLOQda/TBTR1ny8xZ0brKu4ve9hvI4+5YvnbkRU6CmjQxd787817yxGbS8Emw6njNhso8G NP154NSESTUjSOyzqwYGwcYzREYG1vNyArtUktCfSuZpirhUCLO0DDS2tj3Krd2QZKmpAzBO/AB dIfMkkGViwUbjUeGuV2Pe7RCptu952sOCfpBOxal3cKZB8BQsIkKaqUm9PHsUuINfytkzsWeL8Z apJKci/NWqgPzb6szgmzP3APBhJC26gIL0JU7Ce61x4XGJCYT46yR6AhttdWXT9+fo4TXz6IbLb OSIyY2O8F5sTu4aB2EHGN94L8XPy3XFMacvSB6pnFoHMglVpVU5X8r5TmK0H0RYfGstSZyCIysy QZ2exDNJ7wPwvbFYtKg== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-07_05,2026-09-07_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 lowpriorityscore=0 bulkscore=0 clxscore=1015 spamscore=0 impostorscore=0 adultscore=0 phishscore=0 suspectscore=0 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2609070206 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 This is a multi-part message in MIME format. --------------zJ1LFdQXZ47D9PGcRr6DbRsm Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Andrew, I think this commit causes two regressions on powerpc64le-linux, still present on current master (e0d8f6fc386): FAIL: gdb.compile/compile.exp: expect no 5 FAIL: gdb.compile/compile-cplus.exp: expect 5 I bisected these to 32090b27e92cb8fd4998e8e8e65d43f445545bc7. They reproduce on two machines here, one Fedora 43 and one Fedora 44. Both tests check that the memory used by an injected module is released after the compile command finishes. After this commit it is not. Before the commit, with "set debug compile on": allocated 0x5f0 bytes at 0x7ffff7f30000 prot 5 allocated 0x10 bytes at 0x7ffff7db0000 prot 3 allocated 0x34 bytes at 0x7ffff7da0000 prot 1 allocated 0x8 bytes at 0x7ffff7d90000 for registers and none of those addresses appear in "info proc mappings" once the command has finished. After this commit they are still mapped, for example: (gdb) p intptr $1 = (int *) 0x7ffff7db0000 0x00007ffff7db0000 0x00007ffff7dc0000 0x10000 0x0 rw-p so "p *intptr" still reads 5 from the module's memory, which is what the tests check against. That memory is released by munmap_list::~munmap_list in compile/compile-object-load.c, which calls gdbarch_infcall_munmap. On Linux that is linux_infcall_munmap (linux-tdep.c:2960), which looks up "munmap" with find_function_in_inferior. The destructor discards any exception, so a failure there would be silent. The allocations themselves still work, and linux_infcall_mmap looks up "mmap64" through the same function, so whatever changed seems to affect the lookup of "munmap" but not "mmap64". Since GDB 18.1 is due on the 11th, I thought it was worth flagging now. Thanks, Abhay On 02/09/26 21:46, Andrew Burgess wrote: > The find_function_in_inferior function is used when GDB needs to make > an inferior function call as part of expression evaluation, for > example, calling malloc to allocate space in the inferior, or calling > an object's constructor. > > The function lookup has two phases, first we search for full symbols. > If that search fails then we fallback to looking for a minimal symbol. > > The problem I see here is that the full symbol search uses > SEARCH_TYPE_DOMAIN, and has done since commit: > > commit ccf41c248737eb6650211481366c4e1156ce01ae > Date: Thu Mar 30 23:00:26 2023 -0600 > > Use domain_search_flags in lookup_symbol et al > > Prior to this commit the search was done using VAR_DOMAIN, which would > find types, variables, and functions, there was even code in place to > raise an error if the symbol we found was not a function. > > The ccf41c248737eb66 commit switched to SEARCH_TYPE_DOMAIN and removed > the "is a function" check. I think this was a mistake. Given that > find_function_in_inferior is always used to look for a function, I > think we should have switched to SEARCH_FUNCTION_DOMAIN. The "is a > function" check can be removed as the search will now only find > functions. > > So the first thing I fixed in this commit is to change > SEARCH_TYPE_DOMAIN to SEARCH_FUNCTION_DOMAIN in > find_function_in_inferior. > > With that done the next problem we encounter is that if the full > symbol is for a GNU IFUNC then we need to handle this via the minimal > symbol path. For inspiration here I looked at the 'variable: > name_not_typename' rule in the c-exp.y file, where we say: > > /* If we found a function, see if it's > an ifunc resolver that has the same > address as the ifunc symbol itself. > If so, prefer the ifunc symbol. */ > > I think find_function_in_inferior should apply the same logic. To > achieve this I added a call to find_gnu_ifunc and restructured the > code slightly so that after the full symbol lookup the minimal symbol > can come from either calling lookup_minimal_symbol, or from the > find_gnu_ifunc path. > > There are no new tests, but I have been using gdb.base/gnu-ifunc.exp > as a smoke test for this change. When I have glibc debug information > installed I can (by attaching GDB to GDB) see the full symbol lookup > path now triggering, so I know that the updated code path is now being > used. > > It was while reviewing commits: > > commit ca0908d623605250e6d84afb90d742c328e6bb90 > Date: Tue Aug 11 13:12:19 2026 +0000 > > gdb: Keep original IFUNC return type when target type is unknown > > commit de930032d883219559d1dba575f2c0f5359e80fc > Date: Tue Aug 11 13:12:18 2026 +0000 > > gdb: Preserve IFUNC marker when finding inferior functions > > which touched gdb.base/gnu-ifunc.exp that I spotted this bug. > --- > gdb/valops.c | 79 ++++++++++++++++++++++++++-------------------------- > 1 file changed, 40 insertions(+), 39 deletions(-) > > diff --git a/gdb/valops.c b/gdb/valops.c > index 82c796bd254..e214342c40d 100644 > --- a/gdb/valops.c > +++ b/gdb/valops.c > @@ -113,52 +113,53 @@ struct value * > find_function_in_inferior (const char *name, struct objfile **objf_p) > { > struct block_symbol sym; > + bound_minimal_symbol msymbol; > > - sym = lookup_symbol (name, nullptr, SEARCH_TYPE_DOMAIN, nullptr); > - if (sym.symbol != NULL) > + sym = lookup_symbol (name, nullptr, SEARCH_FUNCTION_DOMAIN, nullptr); > + if (sym.symbol != nullptr) > { > - if (objf_p) > - *objf_p = sym.symbol->objfile (); > + msymbol = find_gnu_ifunc (sym.symbol); > + if (msymbol.minsym == nullptr) > + { > + if (objf_p != nullptr) > + *objf_p = sym.symbol->objfile (); > + return value_of_variable (sym.symbol, sym.block); > + } > + } > + else > + msymbol = lookup_minimal_symbol (current_program_space, name); > > - return value_of_variable (sym.symbol, sym.block); > + if (msymbol.minsym != nullptr) > + { > + struct objfile *objfile = msymbol.objfile; > + struct gdbarch *gdbarch = objfile->arch (); > + > + struct type *type; > + CORE_ADDR maddr; > + type = lookup_pointer_type (builtin_type (gdbarch)->builtin_char); > + type = lookup_function_type (type); > + type = lookup_pointer_type (type); > + maddr = msymbol.value_address (); > + minimal_symbol_type minsym_type = msymbol.minsym->type (); > + > + if (minsym_type == mst_text_gnu_ifunc > + || minsym_type == mst_data_gnu_ifunc) > + type->target_type ()->set_is_gnu_ifunc (true); > + > + if (objf_p != nullptr) > + *objf_p = objfile; > + > + return value_from_pointer (type, maddr); > } > else > { > - bound_minimal_symbol msymbol > - = lookup_minimal_symbol (current_program_space, name); > - > - if (msymbol.minsym != NULL) > - { > - struct objfile *objfile = msymbol.objfile; > - struct gdbarch *gdbarch = objfile->arch (); > - > - struct type *type; > - CORE_ADDR maddr; > - type = lookup_pointer_type (builtin_type (gdbarch)->builtin_char); > - type = lookup_function_type (type); > - type = lookup_pointer_type (type); > - maddr = msymbol.value_address (); > - minimal_symbol_type minsym_type = msymbol.minsym->type (); > - > - if (minsym_type == mst_text_gnu_ifunc > - || minsym_type == mst_data_gnu_ifunc) > - type->target_type ()->set_is_gnu_ifunc (true); > - > - if (objf_p) > - *objf_p = objfile; > - > - return value_from_pointer (type, maddr); > - } > + if (!target_has_execution ()) > + error (_("evaluation of this expression " > + "requires the target program to be active")); > else > - { > - if (!target_has_execution ()) > - error (_("evaluation of this expression " > - "requires the target program to be active")); > - else > - error (_("evaluation of this expression requires the " > - "program to have a function \"%s\"."), > - name); > - } > + error (_("evaluation of this expression requires the " > + "program to have a function \"%s\"."), > + name); > } > } > > > base-commit: 9c1937eb7103bee8c329b9c4f5137fcd1726b23d --------------zJ1LFdQXZ47D9PGcRr6DbRsm Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 
Hi Andrew,
I think this commit causes two regressions on powerpc64le-linux,
still present on current master (e0d8f6fc386):
FAIL: gdb.compile/compile.exp: expect no 5
FAIL: gdb.compile/compile-cplus.exp: expect 5
I bisected these to 32090b27e92cb8fd4998e8e8e65d43f445545bc7.  They
reproduce on two machines here, one Fedora 43 and one Fedora 44.
Both tests check that the memory used by an injected module is released
after the compile command finishes.  After this commit it is not.
Before the commit, with "set debug compile on":
allocated 0x5f0 bytes at 0x7ffff7f30000 prot 5
allocated 0x10 bytes at 0x7ffff7db0000 prot 3
allocated 0x34 bytes at 0x7ffff7da0000 prot 1
allocated 0x8 bytes at 0x7ffff7d90000 for registers
and none of those addresses appear in "info proc mappings" once the
command has finished.  After this commit they are still mapped, 
for example:
(gdb) p intptr
$1 = (int *) 0x7ffff7db0000
0x00007ffff7db0000 0x00007ffff7dc0000 0x10000  0x0  rw-p
so "p *intptr" still reads 5 from the module's memory, which is what the
tests check against.
That memory is released by munmap_list::~munmap_list in
compile/compile-object-load.c, which calls gdbarch_infcall_munmap.  On

Linux that is linux_infcall_munmap (linux-tdep.c:2960), which looks up
"munmap" with find_function_in_inferior.  The destructor discards any
exception, so a failure there would be silent.
The allocations themselves still work, and linux_infcall_mmap looks up
"mmap64" through the same function, so whatever changed seems to affect
the lookup of "munmap" but not "mmap64".
Since GDB 18.1 is due on the 11th, I thought it was worth flagging now.
Thanks,
Abhay
On 02/09/26 21:46, Andrew Burgess wrote:
The find_function_in_inferior function is used when GDB needs to make
an inferior function call as part of expression evaluation, for
example, calling malloc to allocate space in the inferior, or calling
an object's constructor.

The function lookup has two phases, first we search for full symbols.
If that search fails then we fallback to looking for a minimal symbol.

The problem I see here is that the full symbol search uses
SEARCH_TYPE_DOMAIN, and has done since commit:

  commit ccf41c248737eb6650211481366c4e1156ce01ae
  Date:   Thu Mar 30 23:00:26 2023 -0600

      Use domain_search_flags in lookup_symbol et al

Prior to this commit the search was done using VAR_DOMAIN, which would
find types, variables, and functions, there was even code in place to
raise an error if the symbol we found was not a function.

The ccf41c248737eb66 commit switched to SEARCH_TYPE_DOMAIN and removed
the "is a function" check.  I think this was a mistake.  Given that
find_function_in_inferior is always used to look for a function, I
think we should have switched to SEARCH_FUNCTION_DOMAIN.  The "is a
function" check can be removed as the search will now only find
functions.

So the first thing I fixed in this commit is to change
SEARCH_TYPE_DOMAIN to SEARCH_FUNCTION_DOMAIN in
find_function_in_inferior.

With that done the next problem we encounter is that if the full
symbol is for a GNU IFUNC then we need to handle this via the minimal
symbol path.  For inspiration here I looked at the 'variable:
name_not_typename' rule in the c-exp.y file, where we say:

      /* If we found a function, see if it's
	 an ifunc resolver that has the same
	 address as the ifunc symbol itself.
	 If so, prefer the ifunc symbol.  */

I think find_function_in_inferior should apply the same logic.  To
achieve this I added a call to find_gnu_ifunc and restructured the
code slightly so that after the full symbol lookup the minimal symbol
can come from either calling lookup_minimal_symbol, or from the
find_gnu_ifunc path.

There are no new tests, but I have been using gdb.base/gnu-ifunc.exp
as a smoke test for this change.  When I have glibc debug information
installed I can (by attaching GDB to GDB) see the full symbol lookup
path now triggering, so I know that the updated code path is now being
used.

It was while reviewing commits:

  commit ca0908d623605250e6d84afb90d742c328e6bb90
  Date:   Tue Aug 11 13:12:19 2026 +0000

      gdb: Keep original IFUNC return type when target type is unknown

  commit de930032d883219559d1dba575f2c0f5359e80fc
  Date:   Tue Aug 11 13:12:18 2026 +0000

      gdb: Preserve IFUNC marker when finding inferior functions

which touched gdb.base/gnu-ifunc.exp that I spotted this bug.
---
 gdb/valops.c | 79 ++++++++++++++++++++++++++--------------------------
 1 file changed, 40 insertions(+), 39 deletions(-)

diff --git a/gdb/valops.c b/gdb/valops.c
index 82c796bd254..e214342c40d 100644
--- a/gdb/valops.c
+++ b/gdb/valops.c
@@ -113,52 +113,53 @@ struct value *
 find_function_in_inferior (const char *name, struct objfile **objf_p)
 {
   struct block_symbol sym;
+  bound_minimal_symbol msymbol;
 
-  sym = lookup_symbol (name, nullptr, SEARCH_TYPE_DOMAIN, nullptr);
-  if (sym.symbol != NULL)
+  sym = lookup_symbol (name, nullptr, SEARCH_FUNCTION_DOMAIN, nullptr);
+  if (sym.symbol != nullptr)
     {
-      if (objf_p)
-	*objf_p = sym.symbol->objfile ();
+      msymbol = find_gnu_ifunc (sym.symbol);
+      if (msymbol.minsym == nullptr)
+	{
+	  if (objf_p != nullptr)
+	    *objf_p = sym.symbol->objfile ();
+	  return value_of_variable (sym.symbol, sym.block);
+	}
+    }
+  else
+    msymbol = lookup_minimal_symbol (current_program_space, name);
 
-      return value_of_variable (sym.symbol, sym.block);
+  if (msymbol.minsym != nullptr)
+    {
+      struct objfile *objfile = msymbol.objfile;
+      struct gdbarch *gdbarch = objfile->arch ();
+
+      struct type *type;
+      CORE_ADDR maddr;
+      type = lookup_pointer_type (builtin_type (gdbarch)->builtin_char);
+      type = lookup_function_type (type);
+      type = lookup_pointer_type (type);
+      maddr = msymbol.value_address ();
+      minimal_symbol_type minsym_type = msymbol.minsym->type ();
+
+      if (minsym_type == mst_text_gnu_ifunc
+	  || minsym_type == mst_data_gnu_ifunc)
+	type->target_type ()->set_is_gnu_ifunc (true);
+
+      if (objf_p != nullptr)
+	*objf_p = objfile;
+
+      return value_from_pointer (type, maddr);
     }
   else
     {
-      bound_minimal_symbol msymbol
-	= lookup_minimal_symbol (current_program_space, name);
-
-      if (msymbol.minsym != NULL)
-	{
-	  struct objfile *objfile = msymbol.objfile;
-	  struct gdbarch *gdbarch = objfile->arch ();
-
-	  struct type *type;
-	  CORE_ADDR maddr;
-	  type = lookup_pointer_type (builtin_type (gdbarch)->builtin_char);
-	  type = lookup_function_type (type);
-	  type = lookup_pointer_type (type);
-	  maddr = msymbol.value_address ();
-	  minimal_symbol_type minsym_type = msymbol.minsym->type ();
-
-	  if (minsym_type == mst_text_gnu_ifunc
-	      || minsym_type == mst_data_gnu_ifunc)
-	    type->target_type ()->set_is_gnu_ifunc (true);
-
-	  if (objf_p)
-	    *objf_p = objfile;
-
-	  return value_from_pointer (type, maddr);
-	}
+      if (!target_has_execution ())
+	error (_("evaluation of this expression "
+		 "requires the target program to be active"));
       else
-	{
-	  if (!target_has_execution ())
-	    error (_("evaluation of this expression "
-		     "requires the target program to be active"));
-	  else
-	    error (_("evaluation of this expression requires the "
-		     "program to have a function \"%s\"."),
-		   name);
-	}
+	error (_("evaluation of this expression requires the "
+		 "program to have a function \"%s\"."),
+	       name);
     }
 }
 

base-commit: 9c1937eb7103bee8c329b9c4f5137fcd1726b23d
--------------zJ1LFdQXZ47D9PGcRr6DbRsm--