Re: [C++ patch] Hookize output_vtable_inherit

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Tue, 24 Jun 2003, Jan Hubicka wrote:
> > On Mon, 2003-06-23 at 23:57, Hans-Peter Nilsson wrote:
> > > On 23 Jun 2003, Mark Mitchell wrote:
> > > > Yes, this is OK.  output_vtable_inherit and assemble_vtable_inherit
> > > > should be working with trees, not RTL, but that's not your fault, so
> > > > there's no reason you should fix it.
> > >
> > > Does -fvtable-gc work anyway these days, or are you just
> > > keeping those functions around for a rainy day?
> >
> > Beats me!  I never really worked with that stuff at all.
>
> It emits the hints to the assembly files for sure, also gas understands
> them.  What happends then is behind me.  (as well as the reason for this
> code)

I know what it's supposed to do.  My point is I know that it
broke totally when we went to the v3 (aka. new) ABI and AFAIK
nobody fixed it and nobody removed the broken feature or the
option.  (Yes, I have pointed this out,
<URL:http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00936.html>).
So, IMHO it should be removed, perhaps later implemented from
scratch, not carried around and be an obstacle to development.
(Hello, Zack!)  Actually before v3, it was broken too (in
binutils).  Anyway, enough whining, time for a PR.

Short recollection of the feature: each class with a virtual
function has its inheritance-chain marked (the .vtable_inherit
pseudo) back to the base class.  Each use of a virtual function
is also marked (the .vtable_entry pseudo). Then, at link-time,
each *row* in the inheritance-chain of a class with virtual
functions is garbage-collected; rows (virtual functions) with no
uses are excluded at link-time (for ELF targets supporting this
feature, and when files are compiled -ffunction-sections
-fdata-sections).  This assumes things about vtable layout, and
most aren't carried over well to the v3 ABI when considering
multiple-inheritance and virtual bases AFAICT.
(RTH can fill in. :-)

Of course, this can't ever work for dynamic linking for classes
visible across the DSO borders, so the feature isn't as useful
as it sounds.  (There's was no machinery handling symbols from,
or exported to DSOs, so nothing could be GC:ed at all unless
-static.)

brgds, H-P