From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71820 invoked by alias); 17 Oct 2016 15:40:59 -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 71797 invoked by uid 89); 17 Oct 2016 15:40:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=H*r:112, terminology, mflr, H*UA:1.2.0 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; Mon, 17 Oct 2016 15:40:48 +0000 Received: by simark.ca (Postfix, from userid 112) id 7220A1E486; Mon, 17 Oct 2016 11:40:46 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id F24F81E124; Mon, 17 Oct 2016 11:40:44 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 17 Oct 2016 15:40:00 -0000 From: Simon Marchi To: Yao Qi Cc: gdb-patches@sourceware.org Subject: Re: [RFC 2/3] Record function descriptor address instead of function address in value In-Reply-To: References: <1476442387-17291-1-git-send-email-yao.qi@linaro.org> <1476442387-17291-3-git-send-email-yao.qi@linaro.org> <1e73fccd01e8a226c95719bb334669d7@simark.ca> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.0 X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00482.txt.bz2 On 2016-10-17 07:40, Yao Qi wrote: > On Fri, Oct 14, 2016 at 6:35 PM, Simon Marchi > wrote: >> On 2016-10-14 06:53, Yao Qi wrote: >>> >>> In this patch, I add a new gdbarch method convert_from_func_addr, >>> which >>> converts function address back to function descriptor address or >>> function pointer address. It is the reversed operation of >>> convert_from_func_ptr_addr. We convert function address to function >>> descriptor address when, >> >> >> I think these could be better named, byt saying what it converts from >> _and_ >> what it converts to. With convert_from_func_addr, we know it takes as >> input >> a function address, but we don't know what it converts it to. What >> about >> something like convert_func_address_to_descriptor (or >> convert_func_addr_to_desc if you prefer shorter names)? >> >> I think that it would also be clearer if we always used the same >> terminology >> (address and descriptor seem good). It is not very intuitive what is >> the >> difference between convert_from_func_ptr_addr and >> convert_from_func_addr. >> "function pointer address" and "function address" sound too close to >> each >> other, so it's easy to confuse them... >> > > If we want to know what these two methods convert to, I'd like to use > "func_addr" and "func_ptr_addr". These two methods can be named as > convert_func_addr_to_func_ptr_addr and > convert_func_ptr_addr_to_func_addr, but they are a little bit long. > Maybe, > remove "convert_" from the names? As you wish, I think it's still clear if the "convert_" is omitted. > "p incr" shows the function descriptor address instead of function > address. > > old ppc64 gdb: > (gdb) p incr > $2 = {int (int)} 0x1000069c > (gdb) p &incr > $3 = (int (*)(int)) 0x1000069c > > old arm gdb: > (gdb) p incr > $2 = {int (int)} 0x104fe > (gdb) p &incr > $3 = (int (*)(int)) 0x104fe > > new ppc64 gdb: > (gdb) p incr > $2 = {int (int)} 0x10020090 > (gdb) p &incr > $3 = (int (*)(int)) @0x10020090: 0x1000069c > > new arm gdb: > (gdb) p incr > $1 = {int (int)} 0x104ff > (gdb) p &incr > $2 = (int (*)(int)) @0x104ff: 0x104fe I am not familiar with ppc64. 0x1000069c is the actual code, and 0x10020090 is the descriptor address? Or is it the other way? > "disassemble incr" is not changed, > > (gdb) disassemble incr > Dump of assembler code for function incr: > 0x000000001000069c <+0>: mflr r0 > 0x00000000100006a0 <+4>: std r0,16(r1) > > "disassemble incr+4,+4" is changed, "incr" means function address > in old gdb, but it means function descriptor address in new gdb. > > old gdb: > (gdb) disassemble incr+4,+4 > Dump of assembler code from 0x100006a0 to 0x100006a4: > 0x00000000100006a0 : std r0,16(r1) > > new gdb: > (gdb) disassemble incr+4,+4 > Dump of assembler code from 0x10020094 to 0x10020098: > 0x0000000010020094 : ps_madds0 f0,f0,f26,f0 > > ... so "disassemble incr+4,+4" makes no sense in new gdb. However, > you can use address instead. > > Similarly, in old gdb, "x/i incr" is to show the first instruction at > function > incr, but in new gdb, it shows the first instruction at function > descriptor. > > (gdb) x/i incr > 0x1000069c : mflr r0 > (gdb) x/i incr > 0x10020090 : .long 0x0 Ok, so it is not the best UI-wise. Is there a way we can add conversions from the descriptor address to the code address in the right circumstances, in order to make it more useful to the user? For example, does it ever make sense to apply the operator + to the descriptor address, or could we always convert to code address for that? Same for disassembly, it probably never makes sense to disassemble the descriptors, so could we add an explicit conversion there?