Hello, Non-PIC executables still need to create PLT entries if the static link determines the function called comes from a shared library. In this case the associated R_VAX_PC32 relocation has to be treated as if it was a R_VAX_PLT32 one. This is similar to how other platforms handle the scenario. Regression-tested successfully with the vax-linux target; running dynamically-linked `bash' on the target system (about the best native testing possible atm) revealed no problems either. bfd/ 2009-06-04 Maciej W. Rozycki <macro@linux-mips.org> * elf32-vax.c (elf_vax_relocate_section): For symbol references from an executable to a shared library treat R_VAX_PC32 relocations as R_VAX_PLT32 ones. OK to apply? Maciej binutils-2.19.51-20090531-vax-pcplt.patch diff -up --recursive --new-file binutils-2.19.51-20090531.macro/bfd/elf32-vax.c binutils-2.19.51-20090531/bfd/elf32-vax.c --- binutils-2.19.51-20090531.macro/bfd/elf32-vax.c 2009-06-01 23:23:15.000000000 +0000 +++ binutils-2.19.51-20090531/bfd/elf32-vax.c 2009-06-01 23:29:01.000000000 +0000 @@ -1534,6 +1534,14 @@ elf_vax_relocate_section (bfd *output_bf } break; + case R_VAX_PC32: + /* If we are creating an executable and the function this + reloc refers to is in a shared lib, then we made a PLT + entry for this symbol and need to handle the reloc like + a PLT reloc. */ + if (info->shared) + goto r_vax_pc32_shared; + /* Fall through. */ case R_VAX_PLT32: /* Relocation is to the entry for this symbol in the procedure linkage table. */ @@ -1595,7 +1603,7 @@ elf_vax_relocate_section (bfd *output_bf case R_VAX_PC8: case R_VAX_PC16: - case R_VAX_PC32: + r_vax_pc32_shared: if (h == NULL || ELF_ST_VISIBILITY (h->other) != STV_DEFAULT || h->forced_local) _______________________________________________ Linux-Vax mailing list Linux-Vax@mail.pergamentum.com http://mail.pergamentum.com/mailman/listinfo/linux-vax