[ppc64-linux]: register CONVERT_FROM_FUNC_PTR_ADDR method

[ppc64-linux]: register CONVERT_FROM_FUNC_PTR_ADDR method

[Jim Blandy]

2003-06-11  Jim Blandy  <jimb@redhat.com>

	* ppc-linux-tdep.c (ppc64_linux_convert_from_func_ptr_addr): New
	function.
	(ppc_linux_init_abi): Register it as the
	CONVERT_FROM_FUNC_PTR_ADDR method under the PPC64 Linux ABI.

Index: gdb/ppc-linux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/ppc-linux-tdep.c,v
retrieving revision 1.28.8.14
diff -c -r1.28.8.14 ppc-linux-tdep.c
*** gdb/ppc-linux-tdep.c	11 Jun 2003 06:46:17 -0000	1.28.8.14
--- gdb/ppc-linux-tdep.c	11 Jun 2003 08:48:28 -0000
***************
*** 894,899 ****
--- 894,932 ----
  }
  
  
+ /* Support for CONVERT_FROM_FUNC_PTR_ADDR(ADDR).
+ 
+    Usually a function pointer's representation is simply the address
+    of the function. On the RS/6000 however, a function pointer is
+    represented by a pointer to a TOC entry. This TOC entry contains
+    three words, the first word is the address of the function, the
+    second word is the TOC pointer (r2), and the third word is the
+    static chain value.  Throughout GDB it is currently assumed that a
+    function pointer contains the address of the function, which is not
+    easy to fix.  In addition, the conversion of a function address to
+    a function pointer would require allocation of a TOC entry in the
+    inferior's memory space, with all its drawbacks.  To be able to
+    call C++ virtual methods in the inferior (which are called via
+    function pointers), find_function_addr uses this function to get the
+    function address from a function pointer.  */
+ 
+ /* Return real function address if ADDR (a function pointer) is in the data
+    space and is therefore a special function pointer.  */
+ 
+ static CORE_ADDR
+ ppc64_linux_convert_from_func_ptr_addr (CORE_ADDR addr)
+ {
+   struct obj_section *s;
+ 
+   s = find_pc_section (addr);
+   if (s && s->the_bfd_section->flags & SEC_CODE)
+     return addr;
+ 
+   /* ADDR is in the data space, so it's a special function pointer. */
+   return ppc64_desc_entry_point (addr);
+ }
+ 
+ 
  /* On 64-bit PowerPC Linux, the ELF header's e_entry field is the
     address of a function descriptor for the entry point function, not
     the actual entry point itself.  So to find the actual address at
***************
*** 1028,1033 ****
--- 1061,1071 ----
    if (tdep->wordsize == 8)
      {
        set_gdbarch_long_double_bit (gdbarch, 16 * TARGET_CHAR_BIT);
+ 
+       /* Handle PPC64 Linux function pointers (which are really
+          function descriptors).  */
+       set_gdbarch_convert_from_func_ptr_addr
+         (gdbarch, ppc64_linux_convert_from_func_ptr_addr);
  
        set_gdbarch_call_dummy_address (gdbarch, ppc64_call_dummy_address);
  

Re: [ppc64-linux]: register CONVERT_FROM_FUNC_PTR_ADDR method

[Kevin Buettner]

On Jun 11,  3:53am, Jim Blandy wrote:

> 2003-06-11  Jim Blandy  <jimb@redhat.com>
> 
> 	* ppc-linux-tdep.c (ppc64_linux_convert_from_func_ptr_addr): New
> 	function.
> 	(ppc_linux_init_abi): Register it as the
> 	CONVERT_FROM_FUNC_PTR_ADDR method under the PPC64 Linux ABI.

Okay, but could you revise the comment to not mention RS/6000 and
to make it clear that the representation in question only pertains
to the 64-bit ABI?

> + /* Support for CONVERT_FROM_FUNC_PTR_ADDR(ADDR).
> + 
> +    Usually a function pointer's representation is simply the address
> +    of the function. On the RS/6000 however, a function pointer is
> +    represented by a pointer to a TOC entry. This TOC entry contains
> +    three words, the first word is the address of the function, the
> +    second word is the TOC pointer (r2), and the third word is the
> +    static chain value.  Throughout GDB it is currently assumed that a
> +    function pointer contains the address of the function, which is not
> +    easy to fix.  In addition, the conversion of a function address to
> +    a function pointer would require allocation of a TOC entry in the
> +    inferior's memory space, with all its drawbacks.  To be able to
> +    call C++ virtual methods in the inferior (which are called via
> +    function pointers), find_function_addr uses this function to get the
> +    function address from a function pointer.  */

Kevin

Re: [ppc64-linux]: register CONVERT_FROM_FUNC_PTR_ADDR method

[Jim Blandy]

Kevin Buettner <kevinb@redhat.com> writes:

> On Jun 11,  3:53am, Jim Blandy wrote:
> 
> > 2003-06-11  Jim Blandy  <jimb@redhat.com>
> > 
> > 	* ppc-linux-tdep.c (ppc64_linux_convert_from_func_ptr_addr): New
> > 	function.
> > 	(ppc_linux_init_abi): Register it as the
> > 	CONVERT_FROM_FUNC_PTR_ADDR method under the PPC64 Linux ABI.
> 
> Okay, but could you revise the comment to not mention RS/6000 and
> to make it clear that the representation in question only pertains
> to the 64-bit ABI?

How's this?

2003-06-11  Jim Blandy  <jimb@redhat.com>

	* ppc-linux-tdep.c (ppc64_linux_convert_from_func_ptr_addr): New
	function.
	(ppc_linux_init_abi): Register it as the
	CONVERT_FROM_FUNC_PTR_ADDR method under the PPC64 Linux ABI.

Index: gdb/ppc-linux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/ppc-linux-tdep.c,v
retrieving revision 1.28.8.17
diff -c -r1.28.8.17 ppc-linux-tdep.c
*** gdb/ppc-linux-tdep.c	12 Jun 2003 21:09:22 -0000	1.28.8.17
--- gdb/ppc-linux-tdep.c	12 Jun 2003 21:09:42 -0000
***************
*** 894,899 ****
--- 894,934 ----
  }
  
  
+ /* Support for CONVERT_FROM_FUNC_PTR_ADDR(ADDR) on PPC64 Linux.
+ 
+    Usually a function pointer's representation is simply the address
+    of the function. On Linux on the 64-bit PowerPC however, a function
+    pointer is represented by a pointer to a TOC entry. This TOC entry
+    contains three words, the first word is the address of the
+    function, the second word is the TOC pointer (r2), and the third
+    word is the static chain value.  Throughout GDB it is currently
+    assumed that a function pointer contains the address of the
+    function, which is not easy to fix.  In addition, the conversion of
+    a function address to a function pointer would require allocation
+    of a TOC entry in the inferior's memory space, with all its
+    drawbacks.  To be able to call C++ virtual methods in the inferior
+    (which are called via function pointers), find_function_addr uses
+    this function to get the function address from a function
+    pointer.  */
+ 
+ /* Return real function address if ADDR (a function pointer) is in the data
+    space and is therefore a special function pointer.  */
+ 
+ static CORE_ADDR
+ ppc64_linux_convert_from_func_ptr_addr (CORE_ADDR addr)
+ {
+   struct obj_section *s;
+ 
+   s = find_pc_section (addr);
+   if (s && s->the_bfd_section->flags & SEC_CODE)
+     return addr;
+ 
+   /* ADDR is in the data space, so it's a pointer to a descriptor, not
+      the entry point.  */
+   return ppc64_desc_entry_point (addr);
+ }
+ 
+ 
  /* On 64-bit PowerPC Linux, the ELF header's e_entry field is the
     address of a function descriptor for the entry point function, not
     the actual entry point itself.  So to find the actual address at
***************
*** 1027,1032 ****
--- 1062,1072 ----
    
    if (tdep->wordsize == 8)
      {
+       /* Handle PPC64 Linux function pointers (which are really
+          function descriptors).  */
+       set_gdbarch_convert_from_func_ptr_addr
+         (gdbarch, ppc64_linux_convert_from_func_ptr_addr);
+ 
        set_gdbarch_call_dummy_address (gdbarch, ppc64_call_dummy_address);
  
        set_gdbarch_in_solib_call_trampoline

Re: [ppc64-linux]: register CONVERT_FROM_FUNC_PTR_ADDR method

[Kevin Buettner]

On Jun 12,  4:11pm, Jim Blandy wrote:

> > Okay, but could you revise the comment to not mention RS/6000 and
> > to make it clear that the representation in question only pertains
> > to the 64-bit ABI?
> 
> How's this?
> 
> 2003-06-11  Jim Blandy  <jimb@redhat.com>
> 
> 	* ppc-linux-tdep.c (ppc64_linux_convert_from_func_ptr_addr): New
> 	function.
> 	(ppc_linux_init_abi): Register it as the
> 	CONVERT_FROM_FUNC_PTR_ADDR method under the PPC64 Linux ABI.

Okay.

Kevin

Re: [ppc64-linux]: register CONVERT_FROM_FUNC_PTR_ADDR method

[Richard Henderson]

On Thu, Jun 12, 2003 at 04:11:31PM -0500, Jim Blandy wrote:
> + /* Support for CONVERT_FROM_FUNC_PTR_ADDR(ADDR) on PPC64 Linux.

Not just Linux, but everywhere else as well.

Indeed, the 64-bit ABI lifts this from 32-bit AIX, so it seems
like this function should be generic in the ppc backend somewhere.


r~

Re: [ppc64-linux]: register CONVERT_FROM_FUNC_PTR_ADDR method

[Kevin Buettner]

On Jun 12,  9:48pm, Richard Henderson wrote:

> On Thu, Jun 12, 2003 at 04:11:31PM -0500, Jim Blandy wrote:
> > + /* Support for CONVERT_FROM_FUNC_PTR_ADDR(ADDR) on PPC64 Linux.
> 
> Not just Linux, but everywhere else as well.
> 
> Indeed, the 64-bit ABI lifts this from 32-bit AIX, so it seems
> like this function should be generic in the ppc backend somewhere.

It does exist in rs6000-tdep.c (as rs6000_convert_from_func_ptr_addr)
and I believe that that function would work for 64-bit PPC Linux also.

So, an alternate approach (to what Jim did) is to export
rs6000_convert_from_func_ptr_addr() via ppc-tdep.h and then register
it in ppc-linux-tdep.c.  That may be preferable in this case since
this function is relatively simple and it could be argued that if
there is a bug in the code, it would likely be a bug for both ABIs. 
Fixing such a bug in one location is preferable to having to fix it in
multiple locations.

OTOH, there's been a recent trend towards separating this kind of
thing out for different ABIs.  E.g, look at all of push_argument
variants in mips-tdep.c.  At one time, not too long ago, all of
the push_argument() variants were rolled into one big function.
(There are some other MIPS related examples that are somewhat
less extreme.)  The reason that this was done is so that fixes
may be made to the support of a given ABI without having to worry
about breaking the support for the other ABIs.

There are pros and cons to each approach and, for this case, I don't
see a clear cut winner.  Since Jim is in the code at the moment, and
has been giving it a lot of thought, I'll leave it up to him to decide
on the best course of action.

Kevin

Re: [ppc64-linux]: register CONVERT_FROM_FUNC_PTR_ADDR method

[Andrew Cagney]

> OTOH, there's been a recent trend towards separating this kind of
> thing out for different ABIs.  E.g, look at all of push_argument
> variants in mips-tdep.c.  At one time, not too long ago, all of
> the push_argument() variants were rolled into one big function.
> (There are some other MIPS related examples that are somewhat
> less extreme.)  The reason that this was done is so that fixes
> may be made to the support of a given ABI without having to worry
> about breaking the support for the other ABIs.

The MIPS has a bit of an ABI explosion problem - 4 ABIs X 32x64 X LExBE 
X FPU X several things I've forgotten.  I don't the PPC has reached that 
point yet :-)

Andrew