Re: [patch] vtable garbage-collection correction to selective6

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

On Thu, 19 Oct 2000, Nick Clifton wrote:
> Hi Hans-Peter,
> 
>   OK, the patch is acceptable, so please do commit with the fix to
>   libiberty/hashtab.c.

Patches are now on the way to gcc-patches for approval; I'll suggest a new
htab_create function called htab_try_create, that causes allocation
failures to return NULL instead of abort (calloc, not xcalloc).

>   I would like to second Ian's opinion that if the vtable garbage
>   collection stuff is going to have to be rewritten, then now would be
>   as a good a time as any.

As time permits, I hope to come up with something that matches gcc3:s
behavior.  I also hope to finish other things...  It is a nice project for
that Someone out there, though.

(FWIW, I interpreted Ian's response more to be "when rewritten" than
"now".  I don't see this as a re-write.  A gcc3 adjustment would probably
be a re-write.)

>   Since I am not familiar with vtables and their garbage collection,
>   perhaps you could explain what it is that they do and what it is
>   that needs to be done in order to support GCC 3.0 ?

I am not really familiar with it, as seen in
<URL:http://gcc.gnu.org/ml/gcc-patches/2000-10/msg00208.html>, but where
there used to be a separate vtable pointer and a separate "secondary"
vtable for every added virtual base class, the tables are now appended to
the main vtable IIRC.  I wish that the gcc3 C++ ABI (a.k.a. the "new ABI")
was documented, but I know of no such documentation.

In short, a virtual table (vtable) holds the function pointers to virtual
functions in a class, such that those function pointers will be found at
the same offset for subclasses (clases that inherit from the class with
the virtual function).  A pointer to the vtable is stored in the object.  
The more vtable pointers, the bigger the object; thus the gcc3 change.
Saying more would be off-topic for this list (and I don't know much more.
:-)

So vtables provide references to functions that might not be used, and it
is beneficial to garbage-collect them too.  The compiler then has to
provide info about which offset to which vtable is used where, and info
about the vtable inheritance tree; that's what .vtable_inherit and
.vtable_entry pseudo-ops are for.  (I wish intended use and such had been
documented somewhere by the authors; not just the terse as.texinfo blurb.  
Perhaps it is.)

Note that -fvtable-gc in GCC is currently broken, see URL above.

brgds, H-P