This is the mail archive of the
mailing list for the binutils project.
Re: [GOLD] advice on powerpc64 .opd handling
On Fri, Aug 17, 2012 at 06:59:57AM -0700, Ian Lance Taylor wrote:
> On Fri, Aug 17, 2012 at 12:23 AM, Alan Modra <email@example.com> wrote:
> > On Thu, Aug 16, 2012 at 10:08:13PM -0700, Ian Lance Taylor wrote:
> >> Normally a C array should be std::vector in C++. This should probably be
> >> std::vector<unsigned int> ent_shndx_;
> >> std::vector<typename elfcpp::Elf_Types<size>::Elf_Off> opd_ent_off_;
> > Even when no resizing will be needed?
> Yes. The overhead is small.
> >> Will this work correctly if the symbol is defined in a SHT_GROUP
> >> section that is discarded?
> > Hasn't something gone horribly if we're trying to call such a
> > function?
> Seems to me that it's normal for a C++ template instantiation. Maybe
> I'm missing something.
I meant function as in a symbol in the object file, not a language
feature. In other words, if gold is relocating a function call then
(a) the section we're relocating is a kept section, and
(b) the function symbol referenced in the reloc will have its code
section kept too, unless something has gone wrong with --gc-sections.
As far as I'm aware, the only way (b) might fail is if the function
symbol is STB_LOCAL, but I thought gcc no longer used local symbols in
comdat groups or linkonce sections. Or is there something I'm missing
about gold symbol resolution?
Australia Development Lab, IBM