This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: R_ARM_GNU_VTINHERIT/R_ARM_GNU_VTENTRY
- To: andreas dot lund at wespot dot com
- Subject: Re: R_ARM_GNU_VTINHERIT/R_ARM_GNU_VTENTRY
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- Date: Mon, 29 Jan 2001 23:32:09 +0100
- CC: gcc at gcc dot gnu dot org, binutils at sources dot redhat dot com
> From: "Andreas Lund" <andreas.lund@wespot.com>
> Date: Mon, 29 Jan 2001 20:36:37 +0100
> Where can i get some information about how to handle the
> "R_ARM_GNU_VTINHERIT" and "R_ARM_GNU_VTENTRY" relocation
> entries?
I CC:ed this to the binutils mailing list which is the proper
forum: it is the assembler that creates the relocations from the
.vtable_inherit and .vtable_entry pseudo-directives, and the
linker that handles them.
In short, they provide garbage-collect information for C++
virtual-function tables when -fvtable-gc is passed to gcc.
I'd recommend not to use that option; it does not function
properly.
> I´m currently trying to make an elf-loader for ecos and
> are having som difficulties with these relocations.
> I´m using gcc 2.95.2 and binutils 2.10.1
These relocations should be gone by the time the executable
(with or without DSO:s) reach your loader. It would be a bug if
they are still present there, assuming your loader expects a
fully linked (or dynamically linked) executable. Do you see
these relocations in the executable?
brgds, H-P