This is the mail archive of the
mailing list for the GDB project.
Re: [rfc/cp] method stub assertions
- From: mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)
- To: drow at mvista dot com
- Cc: gdb-patches at sources dot redhat dot com
- Date: Tue, 6 Jan 2004 13:23:58 -0500 (EST)
- Subject: Re: [rfc/cp] method stub assertions
> That's a nice hypothesis. Unfortunately it's completely wrong :)
> First of all, TYPE_CODE_MEMBER and TYPE_CODE_METHOD are siblings.
> MEMBER is used for data variables, not to wrap methods.
I think you mean: TYPE_CODE_MEMBER is used for pointers to data
It's a really bad name. How about:
TYPE_CODE_PTR # pointer to memory
TYPE_CODE_PMD # pointer to member data
TYPE_CODE_PMF_PLAIN # pointer to non-static non-virtual function
TYPE_CODE_PMF_VIRTUAL # pointer to virtual function
TYPE_CODE_PTR has a raw CORE_ADDR, just like it does now.
TYPE_CODE_PMD has a class type and a data offset.
TYPE_CODE_PMF_PLAIN has a class type and a raw CORE_ADDR.
TYPE_CODE_PMF_VIRTUAL has a class type and a vtbl offset.
> The debug information for A::bad6 does not specify that it is a method.
> Rather only the debug info for class A specifies that it has a method
> named A::bad6. Take a look at a readelf -wi dump of your testcase to
> see how this works.
How can we make &A::bad6 have a different type than &f1 ?
> Currently they do appear as TYPE_CODE_METHOD. I think that they
> probably shouldn't. A pointer to a static method is a function
> pointer, not a pointer-to-member. Similarly static variables should
> probably not be TYPE_CODE_MEMBER.
I agree that &A::static_function should be TYPE_CODE_PTR.
It's easy to figure that out even if A::static_function is
TYPE_CODE_METHOD, because we can look at TYPE_FLAG_STATIC
at the time we evalue the "&" operator.