This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: -fvtable-gc


On Wed, Aug 15, 2001 at 10:56:37AM +0100, Jason Merrill wrote:
> How were you thinking of reimplementing it in binutils?

I'd do it with a couple of new sections instead of putting
this stuff into the symbol+relocation tables:

	.gnu.vtstrtab
		sh_type SHT_STRTAB
		sh_flags 0

		A strtab like any other.  Could be shared with
		the regular .strtab or .dynstr if we wanted to
		complicate the implementation.

	.gnu.vtinherit
		sh_type SHT_GNU_vtinherit	(maybe 0x6ffffff0)
		sh_link .gnu.vtstrtab
		sh_info .gnu.vtref
		sh_flags SHF_INFO_LINK

		typedef struct
		{
		  ElfW(Word) vti_derived;	/* string table index */
		  ElfW(Word) vti_base;		/* string table index */
		  ElfW(Word) vti_size;		/* size of this vtable */
		  ElfW(Word) vti_refs;		/* offset info .gnu.vtref */
		} ElfW(Vtinherit);

	.gnu.vtref
		sh_type SHT_GNU_vtref		(maybe 0x6ffffff1)
		sh_flags 0
		sh_entsize <size of a pointer>

		Array of bit vectors.  Each bit vector is
		an array of bytes, indexed little-bit-endian.
		Bit N on indicates that the entry at offset
		N*st_entsize is used.

The tricky bit is knowing whether you've got all of the information
that you need -- with the current implementation you don't know.  I
figure that if you compile a file with -fvtable-gc and it makes no
vtable references, then you must have a zero-sized .gnu.vtref section.
If there is no .gnu.vtref section, then assume that the file was not
compiled with -fvtable-gc and you're missing information.

When the linker is given incomplete data, i.e., one or more objects
do not have .gnu.vtref sections:

  A relocatable link (-r) would warn and then discard all vtable data.

  A final link would warn and then ignore vtable sections for the
  purposes of --gc-sections.

By copying vtable section data into shared libraries, we open the
possibility to do some vtable-gc in the presence of shared libraries.
The assumption would be that if a library doesn't mention a class
in .gnu.vtinherit, then no future compatible version of the library
will mention the class either, and thus it is safe to assume that no
methods for that class will be referenced by the library.  If, however,
a library does mention a class, then the contents of its .gnu.vtref
are immaterial -- a future version of the library could reference any
of the vtable entries.

Oh, I think we'll need a fake base class for all C++ classes that
consists of just the RTTI information.  This has two effects: (1) we
can legitimately discard rtti info when it isn't used and (2) we don't
have to special-case that entry in the vtable.

Can anyone poke holes in this idea?


r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]