This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: DWARF2 vtable_elem_location
- To: Jason Merrill <jason at redhat dot com>
- Subject: Re: DWARF2 vtable_elem_location
- From: Daniel Berlin <dberlin at redhat dot com>
- Date: 04 Aug 2000 19:30:14 -0400
- Cc: gcc at gcc dot gnu dot org, g++-local at cygnus dot com
- References: <m31z0be4x7.fsf@dan2.cygnus.com><u9u2d0n3mc.fsf@yorick.soma.redhat.com>
Jason Merrill <jason@redhat.com> writes:
> >>>>> Daniel Berlin <dberlin@redhat.com> writes:
>
> > Currently, g++ only outputs the slot *number* for a vtable location of
> > a function.
>
> > The standard says it is supposed to be the address of the slot in the
> > vtable.
>
> > It would really make GDB's life easier for C++ debugging (seriously,
> > I'd be able to remove so much crufty code it's not funny) if it would
> > actually give us the real address in the vtable.
>
> The cruft would still be needed for stabs, wouldn't it?
>
> Jason
Technically.
However, it'll completely break when the new ABI is turned on, and i
for one, don't plan on fixing it. It's rather easy to make DWARF2 work
with the new ABI.
In fact, if you guys would turn on DWARF2 as the default for gcc 3.0,
I could make a good case for deprecating STABS in the next version of
GDB, and removing it thereafter. It really holds us back, because i'd
completely break the stabs reader if i restructured the other symbol
readers, which have symbol formats that have things like nice indexes
and whatnot, to take advantage.
In fact, I could reduce the memory usage of GDB, and speed it up, by a
few orders of magnitude, easily, with about a week or two worth of
work.
--Dan