From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76687 invoked by alias); 17 Oct 2016 11:40:17 -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 76671 invoked by uid 89); 17 Oct 2016 11:40:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=AFTER, mains, terminology, byt X-HELO: mail-oi0-f67.google.com Received: from mail-oi0-f67.google.com (HELO mail-oi0-f67.google.com) (209.85.218.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Oct 2016 11:40:06 +0000 Received: by mail-oi0-f67.google.com with SMTP id d132so12211637oib.2 for ; Mon, 17 Oct 2016 04:40:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=TBrD3PFeGmhhUw0jFUdJGEevaEHvXaz6bMYB0yfaj7s=; b=RSDitcUFhOIaUz9P8yrwUxVNiKHW2j+KtB8OVE1Yo578U8kMPmIB3GuXnrb2AOpDG9 nURqi/SKaHFQ/jQh5ZF6HPCP55awQKtkLUXtTPtNda0avGnO/I0RiS6DRHgWAdcgxyhG Cwv3wWBTyJvzs7HLCFeCGDYQNZ1QktzbE9/o0rifFjfvEAon98Jhkpl5j+a8m+zpIUgC 2KgFNOxJ1t1VSksl2e4b6bcJLGD0m/cG9J6KNeq2idOVQt9+2YmUqzPOxEdp3MBQyjEz 6hMB09mOGMqSZHvEjMuXruxhywhu7vw/mkS9uScHNugdRsb4VgB07QxOnQzphvfJod0g IhtA== X-Gm-Message-State: AA6/9RlNRfEfV6RGWu4jvYu5u30E/VJeFTAV66GxkFg4bTlAegRonKBe/JWl/Z95tZccnn20pYEiZ9WmaxntWQ== X-Received: by 10.202.4.17 with SMTP id 17mr16758881oie.91.1476704405074; Mon, 17 Oct 2016 04:40:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.193.5 with HTTP; Mon, 17 Oct 2016 04:40:04 -0700 (PDT) In-Reply-To: <1e73fccd01e8a226c95719bb334669d7@simark.ca> References: <1476442387-17291-1-git-send-email-yao.qi@linaro.org> <1476442387-17291-3-git-send-email-yao.qi@linaro.org> <1e73fccd01e8a226c95719bb334669d7@simark.ca> From: Yao Qi Date: Mon, 17 Oct 2016 11:40:00 -0000 Message-ID: Subject: Re: [RFC 2/3] Record function descriptor address instead of function address in value To: Simon Marchi Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00473.txt.bz2 On Fri, Oct 14, 2016 at 6:35 PM, Simon Marchi wro= te: > 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 _an= d_ > what it converts to. With convert_from_func_addr, we know it takes as in= put > 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 terminol= ogy > (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? >> 3. User visible changes >> >> This patch brings several user visible changes, which look more >> accurate, shown by this table below, >> >> COMMAND BEFORE AFTER >> p main main function address main function descriptor >> address >> disass main disassembly function main not changed >> disass main+4,+4 disassembly 4 bytes from disassembly 4 bytes from >> function main address + 4 main's function descript= or >> + 4 >> x/i main show one instruction on show one instruction on >> main's >> function main address function descriptor >> >> Although the latter looks inconvenient, that is consistent to the >> meaning on C language level. Due to these changes, test cases are >> adjusted accordingly. > > > Could you provide example of the actual output of those commands, before = and > after? It is not clear to me what the difference will be. > "p incr" shows the function descriptor address instead of function address. old ppc64 gdb: (gdb) p incr $2 =3D {int (int)} 0x1000069c (gdb) p &incr $3 =3D (int (*)(int)) 0x1000069c old arm gdb: (gdb) p incr $2 =3D {int (int)} 0x104fe (gdb) p &incr $3 =3D (int (*)(int)) 0x104fe new ppc64 gdb: (gdb) p incr $2 =3D {int (int)} 0x10020090 (gdb) p &incr $3 =3D (int (*)(int)) @0x10020090: 0x1000069c new arm gdb: (gdb) p incr $1 =3D {int (int)} 0x104ff (gdb) p &incr $2 =3D (int (*)(int)) @0x104ff: 0x104fe "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 funct= ion 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 --=20 Yao (=E9=BD=90=E5=B0=A7)