From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46165 invoked by alias); 10 Apr 2018 21:20:20 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 46058 invoked by uid 89); 10 Apr 2018 21:20:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.3 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3 autolearn=ham version=3.3.2 spammy=angle, Hx-languages-length:1718 X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 10 Apr 2018 21:20:18 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1346DEB70A; Tue, 10 Apr 2018 21:20:17 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7BE272026DFD; Tue, 10 Apr 2018 21:20:16 +0000 (UTC) From: Pedro Alves Subject: Re: [PATCH v2 02/15] Fix calling ifunc functions when resolver has debug info and different name To: Simon Marchi , gdb-patches@sourceware.org References: <20180325191943.8246-1-palves@redhat.com> <20180325191943.8246-3-palves@redhat.com> Message-ID: <23402c69-6c9d-ddc5-4178-2eb281900157@redhat.com> Date: Tue, 10 Apr 2018 21:20:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-04/txt/msg00199.txt.bz2 Hi Simon, On 04/01/2018 04:44 AM, Simon Marchi wrote: >> diff --git a/gdb/c-exp.y b/gdb/c-exp.y >> index 8dc3c068a5e..e2ea07cd792 100644 >> --- a/gdb/c-exp.y >> +++ b/gdb/c-exp.y >> @@ -1081,7 +1081,9 @@ variable: name_not_typename >> is important for example for "p >> *__errno_location()". */ >> symbol *alias_target >> - = find_function_alias_target (msymbol); >> + = (msymbol.minsym->type != mst_text_gnu_ifunc >> + ? find_function_alias_target (msymbol) >> + : NULL); >> if (alias_target != NULL) >> { >> write_exp_elt_opcode (pstate, OP_VAR_VALUE); >> > > Just one question, to which I really don't have a preconceived answer: > > Would it make sense to add that filtering to find_function_alias_target or > another function deeper in the call chain instead? In other words, would > it ever make sense for find_function_alias_target to return an non-NULL > result for an mst_text_gnu_ifunc minimal symbol? For ifuncs, find_function_alias_target will finds the debug symbol for the resolver. If that has a different name from the ifunc (it will if you use gcc's attribute ifunc, then it'll work the same as any other minsym, in the sense that it'll find an alias. So from that angle, the function works as intended, and it wasn't clear that we'll always want to treat ifuncs differently. Note this is the only caller of find_function_alias_target currently. Another reason for leaving the check here is that patch #4 adds another case of "do this for ifuncs" just above this code, but for the "sym.symbol" case. It felt better to keep both of the "for ifunc, do this" cases close together. Thanks, Pedro Alves