Re: [RFC 2/3] Record function descriptor address instead of function address in value

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2016-10-17 07:40, Yao Qi wrote:
> On Fri, Oct 14, 2016 at 6:35 PM, Simon Marchi <simon.marchi@polymtl.ca> 
> 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 <incr>
> (gdb) p &incr
> $3 = (int (*)(int)) 0x1000069c <incr>
> 
> old arm gdb:
> (gdb) p incr
> $2 = {int (int)} 0x104fe <incr>
> (gdb) p &incr
> $3 = (int (*)(int)) 0x104fe <incr>
> 
> new ppc64 gdb:
> (gdb) p incr
> $2 = {int (int)} 0x10020090 <incr>
> (gdb) p &incr
> $3 = (int (*)(int)) @0x10020090: 0x1000069c <incr>
> 
> new arm gdb:
> (gdb) p incr
> $1 = {int (int)} 0x104ff <incr>
> (gdb) p &incr
> $2 = (int (*)(int)) @0x104ff: 0x104fe <incr>

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 <incr+4>: std     r0,16(r1)
> 
> new gdb:
> (gdb) disassemble incr+4,+4
> Dump of assembler code from 0x10020094 to 0x10020098:
>    0x0000000010020094 <incr+4>: 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 <incr>: mflr    r0
> (gdb) x/i incr
>    0x10020090 <incr>: .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?