C++ pointer-to-member handling broken?

C++ pointer-to-member handling broken?

[Ulrich Weigand]

Hello,

it looks like the handling of C++ pointers to members is broken at the moment;
the assumptions GDB makes about how these data structures are layed out by
the compiler do not match what any (recent) GCC does ...

Two issues that are currently causing testcase failures on s390x:

- For pointer to data members, GDB assumes (in cp_print_class_member
  (cp-valprint.c)) that these are of type 'int' and hold the byte
  offset.

  This is incorrect on s390x (and other 64-bit platforms): they
  should by of type 'ptrdiff_t' (which is 'long') according to
  the GCC 3.x C++ ABI.

  Note that GDB is even incompatible with itself here: in 
  value_struct_elt_for_reference (valops.c), when it generates
  a pointer-to-data-member value, they are stored as *addresses*
  (e.g. 64-bit).

  This causes a test case failure on s390x-ibm-linux:
  FAIL: gdb.cp/classes.exp: print Bar::z

- For pointer to member functions, GDB needs to be aware of how
  the compiler distinguishes between virtual and non-virtual
  member functions.  This is currently done using these macros
  in 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))

  This does not adhere to the GCC 3.x ABI on any platform, which
  uses a pair of (address or vtable offset) and this-adjust delta,
  where virtual functions are marked either by the *low* bit of
  the address, or by the low bit of the delta, depending on whether
  the platform supports functions starting at odd addresses or not.

  On s390(x), the low bit of the address is used, while this test
  checks the high bit.  Thus, virtual functions are not detected
  correctly.

  Even worse, on s390x the default starting address of executables
  is 0x80000000.  This means that *normal* functions are frequently
  misdetected as virtual; this causes the test case failure:
  FAIL: gdb.cp/printmethod.exp: print virtual method.

Any suggestions how to fix this?  I guess there should be some target
interface that allows the target to define the format of pointers to
members according to the platform's ABI ...

Bye,
Ulrich
-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de