This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfc/cp] method stub assertions
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Michael Elizabeth Chastain <mec dot gnu at mindspring dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Tue, 6 Jan 2004 14:02:10 -0500
- Subject: Re: [rfc/cp] method stub assertions
- References: <20040106182358.32BCA4B35A@berman.michael-chastain.com>
On Tue, Jan 06, 2004 at 01:23:58PM -0500, Michael Chastain wrote:
> > 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
> members.
Blah, no, it's supposed to be used for both pointer-to-member and
pointer-to-member-function. You're right.
> 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.
No. None of this are necessary. The details of how a
pointer-to-member work should never be exposed to the GDB type
machinery; it's just a pointer-to-member, leave it at that.
If you want to be able to call through them use the DWARF-2 location
expression machinery and DW_AT_use_location.
> > 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.
>
> Ouch.
>
> How can we make &A::bad6 have a different type than &f1 ?
As I suggested in my last message, by making 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.
>
> Michael C
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer