From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104560 invoked by alias); 1 Apr 2018 03:44:36 -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 104536 invoked by uid 89); 1 Apr 2018 03:44:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=non-NULL, nonNULL, H*M:1bc5, non-null X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 01 Apr 2018 03:44:33 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 80CBE1E030; Sat, 31 Mar 2018 23:44:31 -0400 (EDT) Subject: Re: [PATCH v2 02/15] Fix calling ifunc functions when resolver has debug info and different name To: Pedro Alves , gdb-patches@sourceware.org References: <20180325191943.8246-1-palves@redhat.com> <20180325191943.8246-3-palves@redhat.com> From: Simon Marchi Message-ID: Date: Sun, 01 Apr 2018 03:44:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180325191943.8246-3-palves@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-04/txt/msg00008.txt.bz2 On 2018-03-25 03:19 PM, Pedro Alves wrote: > Currently, on Fedora 27 (glibc 2.26), if you try to call strlen in the > inferior you get: > > (gdb) p strlen ("hello") > $1 = (size_t (*)(const char *)) 0x7ffff554aac0 <__strlen_avx2> > > strlen is an ifunc function, and what we see above is the result of > calling the ifunc resolver in the inferior. That returns a pointer to > the actual target function that implements strlen on my machine. GDB > should have turned around and called the resolver automatically > without the user noticing. > > This is was caused by commit: > > commit bf223d3e808e6fec9ee165d3d48beb74837796de > Date: Mon Aug 21 11:34:32 2017 +0100 > > Handle function aliases better (PR gdb/19487, errno printing) > > which added the find_function_alias_target call to c-exp.y, to try to > find an alias with debug info for a minsym. For ifunc symbols, that > finds the ifunc's resolver if it has debug info (in the example it's > called "strlen_ifunc"), with the result that GDB calls that as a > regular function. > > After this commit, we get now get: > > (top-gdb) p strlen ("hello") > '__strlen_avx2' has unknown return type; cast the call to its declared return type > > Which is correct, because __strlen_avx2 is written in assembly. > That'll be improved in a following patch, though. > > gdb/ChangeLog: > yyyy-mm-dd Pedro Alves > > * c-exp.y (variable production): Skip finding an alias for ifunc > symbols. > --- > gdb/c-exp.y | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > 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? Simon Simon