This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: powepc64le gold linking problem


On Mon, Nov 24, 2014 at 01:35:08PM +0000, Jay Foad wrote:
> On 24 November 2014 at 12:15, Alan Modra <amodra@gmail.com> wrote:
> > (If not, I
> > don't see how ld.bfd would link the object OK.)
> 
> Well somehow it manages to. Maybe it's something to do with this code
> in ppc64_elf_branch_reloc (in bfd/elf64-ppc.c):

Nope.  ppc64_elf_branch_reloc is only used when linking a ppc64 ELF
object to some other format output, such as srec.

>       elf_symbol_type *elfsym = (elf_symbol_type *) symbol;
> 
>       if (symbol->section->owner != abfd
>           && abiversion (symbol->section->owner) >= 2)
>         {
>           unsigned int i;
> 
>           for (i = 0; i < symbol->section->owner->symcount; ++i)
>             {
>               asymbol *symdef = symbol->section->owner->outsymbols[i];
> 
>               if (strcmp (symdef->name, symbol->name) == 0)
>                 {
>                   elfsym = (elf_symbol_type *) symdef;
>                   break;
>                 }
>             }
>         }
>       reloc_entry->addend
>         += PPC64_LOCAL_ENTRY_OFFSET (elfsym->internal_elf_sym.st_other);
> 
> I don't understand the purpose of this code, but it looks like it
> might be intentionally using the st_other bits from a different
> symbol.

The above code is finding the st_other bits in the symbol definition.
The generic BFD linker doesn't handle merging st_other, or anything
else ELF specific.

-- 
Alan Modra
Australia Development Lab, IBM


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