METHOD_PTR_*?

METHOD_PTR_*?

[Andrew Cagney]

Hello,

 From value.h:

/* Pointer to member function.  Depends on compiler implementation.  */

#define METHOD_PTR_IS_VIRTUAL(ADDR)  ((ADDR) & 0x80000000)
#define METHOD_PTR_FROM_VOFFSET(OFFSET) (0x80000000 + (OFFSET))
#define METHOD_PTR_TO_VOFFSET(ADDR) (~0x80000000 & (ADDR))

It also depends on the underlying architecture - not very 64-bit 
friendly :-/

Andrew

Re: METHOD_PTR_*?

[Daniel Jacobowitz]

On Tue, Nov 09, 2004 at 03:57:02PM -0500, Andrew Cagney wrote:
> Hello,
> 
> From value.h:
> 
> /* Pointer to member function.  Depends on compiler implementation.  */
> 
> #define METHOD_PTR_IS_VIRTUAL(ADDR)  ((ADDR) & 0x80000000)
> #define METHOD_PTR_FROM_VOFFSET(OFFSET) (0x80000000 + (OFFSET))
> #define METHOD_PTR_TO_VOFFSET(ADDR) (~0x80000000 & (ADDR))
> 
> It also depends on the underlying architecture - not very 64-bit 
> friendly :-/

Yuck!

If I'm reading this right, it corresponded to some old compiler's
implementation.  But nowadays we fake it in
value_struct_elt_for_reference.  This is a bit tricky to untangle, but
I think this could be solved entirely in eval.c (and the one place we
print "virtual" and ditching the remaining bits.  I wonder if anything
in the testsuite exercises this?

-- 
Daniel Jacobowitz

Re: METHOD_PTR_*?

[Andrew Cagney]

Daniel Jacobowitz wrote:
> On Tue, Nov 09, 2004 at 03:57:02PM -0500, Andrew Cagney wrote:
> 
>>Hello,
>>
>From value.h:
>>
>>/* Pointer to member function.  Depends on compiler implementation.  */
>>
>>#define METHOD_PTR_IS_VIRTUAL(ADDR)  ((ADDR) & 0x80000000)
>>#define METHOD_PTR_FROM_VOFFSET(OFFSET) (0x80000000 + (OFFSET))
>>#define METHOD_PTR_TO_VOFFSET(ADDR) (~0x80000000 & (ADDR))
>>
>>It also depends on the underlying architecture - not very 64-bit 
>>friendly :-/
> 
> 
> Yuck!

Can it for the moment be moved out of value.h?

Andrew

> If I'm reading this right, it corresponded to some old compiler's
> implementation.  But nowadays we fake it in
> value_struct_elt_for_reference.  This is a bit tricky to untangle, but
> I think this could be solved entirely in eval.c (and the one place we
> print "virtual" and ditching the remaining bits.  I wonder if anything
> in the testsuite exercises this?
> 

Re: METHOD_PTR_*?

[Daniel Jacobowitz]

On Mon, Nov 15, 2004 at 08:13:00PM -0500, Andrew Cagney wrote:
> Daniel Jacobowitz wrote:
> >On Tue, Nov 09, 2004 at 03:57:02PM -0500, Andrew Cagney wrote:
> >
> >>Hello,
> >>
> >>From value.h:
> >>
> >>/* Pointer to member function.  Depends on compiler implementation.  */
> >>
> >>#define METHOD_PTR_IS_VIRTUAL(ADDR)  ((ADDR) & 0x80000000)
> >>#define METHOD_PTR_FROM_VOFFSET(OFFSET) (0x80000000 + (OFFSET))
> >>#define METHOD_PTR_TO_VOFFSET(ADDR) (~0x80000000 & (ADDR))
> >>
> >>It also depends on the underlying architecture - not very 64-bit 
> >>friendly :-/
> >
> >
> >Yuck!
> 
> Can it for the moment be moved out of value.h?

What would that accomplish?  Where would it move to?

-- 
Daniel Jacobowitz

Re: METHOD_PTR_*?

[Andrew Cagney]

Daniel Jacobowitz wrote:
> On Mon, Nov 15, 2004 at 08:13:00PM -0500, Andrew Cagney wrote:
> 
>>Daniel Jacobowitz wrote:
>>
>>>On Tue, Nov 09, 2004 at 03:57:02PM -0500, Andrew Cagney wrote:
>>>
>>>
>>>>Hello,
>>>>
>>>
>>>From value.h:
>>>
>>>>/* Pointer to member function.  Depends on compiler implementation.  */
>>>>
>>>>#define METHOD_PTR_IS_VIRTUAL(ADDR)  ((ADDR) & 0x80000000)
>>>>#define METHOD_PTR_FROM_VOFFSET(OFFSET) (0x80000000 + (OFFSET))
>>>>#define METHOD_PTR_TO_VOFFSET(ADDR) (~0x80000000 & (ADDR))
>>>>
>>>>It also depends on the underlying architecture - not very 64-bit 
>>>>friendly :-/
>>>
>>>
>>>Yuck!
>>
>>Can it for the moment be moved out of value.h?
> 
> 
> What would that accomplish?  Where would it move to?

It would remove it from value.h.  cp-abi.h?

Andrew

Re: METHOD_PTR_*?

[Daniel Jacobowitz]

On Mon, Nov 15, 2004 at 09:21:20PM -0500, Andrew Cagney wrote:
> Daniel Jacobowitz wrote:
> >On Mon, Nov 15, 2004 at 08:13:00PM -0500, Andrew Cagney wrote:
> >
> >>Daniel Jacobowitz wrote:
> >>
> >>>On Tue, Nov 09, 2004 at 03:57:02PM -0500, Andrew Cagney wrote:
> >>>
> >>>
> >>>>Hello,
> >>>>
> >>>
> >>>>From value.h:
> >>>
> >>>>/* Pointer to member function.  Depends on compiler implementation.  */
> >>>>
> >>>>#define METHOD_PTR_IS_VIRTUAL(ADDR)  ((ADDR) & 0x80000000)
> >>>>#define METHOD_PTR_FROM_VOFFSET(OFFSET) (0x80000000 + (OFFSET))
> >>>>#define METHOD_PTR_TO_VOFFSET(ADDR) (~0x80000000 & (ADDR))
> >>>>
> >>>>It also depends on the underlying architecture - not very 64-bit 
> >>>>friendly :-/
> >>>
> >>>
> >>>Yuck!
> >>
> >>Can it for the moment be moved out of value.h?
> >
> >
> >What would that accomplish?  Where would it move to?
> 
> It would remove it from value.h.

That doesn't really answer my question...  I assume that you want to
move it so that value.h only contains some set of "blessed" "struct
value" related routines.  But this has no home obviously more
appropriate than its current home.

>  cp-abi.h?

How about cp-support.h?

-- 
Daniel Jacobowitz

Re: METHOD_PTR_*?

[Andrew Cagney]

>>>>Can it for the moment be moved out of value.h?
>>>
>>>
>>>What would that accomplish?  Where would it move to?
>>
>>It would remove it from value.h.
> 
> 
> That doesn't really answer my question...  I assume that you want to
> move it so that value.h only contains some set of "blessed" "struct
> value" related routines.  But this has no home obviously more
> appropriate than its current home.

It's got a lot closer to C++ than value.

>> cp-abi.h?
> 
> 
> How about cp-support.h?

Done.

Andrew

Re: METHOD_PTR_*?

[Ulrich Weigand]

Daniel Jacobowitz wrote:
>On Tue, Nov 09, 2004 at 03:57:02PM -0500, Andrew Cagney wrote:
>> Hello,
>>
>> From value.h:
>>
>> /* Pointer to member function.  Depends on compiler implementation.  */
>>
>> #define METHOD_PTR_IS_VIRTUAL(ADDR)  ((ADDR) & 0x80000000)
>> #define METHOD_PTR_FROM_VOFFSET(OFFSET) (0x80000000 + (OFFSET))
>> #define METHOD_PTR_TO_VOFFSET(ADDR) (~0x80000000 & (ADDR))
>>
>> It also depends on the underlying architecture - not very 64-bit
>> friendly :-/
>
>Yuck!
>
>If I'm reading this right, it corresponded to some old compiler's
>implementation.  But nowadays we fake it in
>value_struct_elt_for_reference.  This is a bit tricky to untangle, but
>I think this could be solved entirely in eval.c (and the one place we
>print "virtual" and ditching the remaining bits.  I wonder if anything
>in the testsuite exercises this?

This is responsible for these testsuite failures on s390x-ibm-linux:
FAIL: gdb.cp/classes.exp: print Bar::z
FAIL: gdb.cp/printmethod.exp: print virtual method.

(s390x tends to exercise this bug as the default load address for
executables happens to be 0x80000000.)

I don't think this can be handled entirely in eval.c; while there are
some cases where gdb code itself sets up something like a pointer-to-
member-function (which you could conceivably handle internally), you
also need to be able to handle a *real* p-t-m set up by the target
compiler.  However, there doesn't appear to be any real testsuite
coverage for that case.

As the format of a pointer-to-member is defined by the platform ABI,
I guess some sort of target callback would be appropriate.

For GNU/Linux using GCC 3.x, the format is defined for IA64 at
http://www.codesourcery.com/cxx-abi/abi.html#member-pointers
and non-IA64 platforms use variants of that scheme; here's what
the GCC internals doc has to say about it:

`TARGET_PTRMEMFUNC_VBIT_LOCATION'
     The C++ compiler represents a pointer-to-member-function with a
     struct that looks like:

            struct {
              union {
                void (*fn)();
                ptrdiff_t vtable_index;
              };
              ptrdiff_t delta;
            };

     The C++ compiler must use one bit to indicate whether the function
     that will be called through a pointer-to-member-function is
     virtual.  Normally, we assume that the low-order bit of a function
     pointer must always be zero.  Then, by ensuring that the
     vtable_index is odd, we can distinguish which variant of the union
     is in use.  But, on some platforms function pointers can be odd,
     and so this doesn't work.  In that case, we use the low-order bit
     of the `delta' field, and shift the remainder of the `delta' field
     to the left.



Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com