This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [GOLD] advice on powerpc64 .opd handling
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?
> > + shndx = this->symbol_section_and_value(r_sym, &value,
> > + &is_ordinary);
>
> This isn't necessarily something to worry about right now, but
> symbol_section_and_value is kind of a slow function.
Yes, I noticed that. Gloabl symbols here are a rarity.
> > + if (!can_plt_call)
> > + {
> > + if (parameters->options().output_is_executable())
>
> What should happen for a shared library here? Should this be
> !relocatable() instead?
This was copied from bfd/elf64-ppc.c without much thought. Now that
you mention it, I'm not sure that the bfd code is correct.
Investigating.
>
> > + if (value >= opd_addr
> > + && value < opd_addr + symobj->section_size(shndx))
> > + {
> > + symobj->get_opd_ent(value - opd_addr, &shndx, &value);
> > + value += (symobj->output_section(shndx)->address()
> > + + symobj->output_section_offset(shndx));
>
> Should get_opd_ent double-check that it is not returning an undefined symbol?
I suppose that could be caused by an invalid object file. Valid OPD
entries point at locally defined functions.
> 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?
--
Alan Modra
Australia Development Lab, IBM