Control: reassign -1 binutils Control: retitle -1 ld on sparc64 converts R_SPARC_32 to R_SPARC_RELATIVE Control: affects -1 src:x264 Control: tags -1 upstream patch Control: forwarded -1 asdf On Tue, 21 Jul 2015 22:35:49 +0200 Andreas Cadhalpun <andreas.cadhalpun@googlemail.com> wrote: > On 21.07.2015 21:44, Carlos O'Donell wrote: > > Does the problem always reproduce or just sometimes? > > Always. > > > If it's just sometimes then it's much much harder to figure out what's wrong. > > If it were just sometimes, I wouldn't have been able to trace it to libx264... > > > You'll need a dedicated person to track down exactly what is the > > concurrency issue and why it's failing. > > What I don't understand is why it only fails for libx264, but e.g. libx265 is fine. > Also, I don't see how the code, where the crash happens, can possibly crash: > From do-rel.h [1]: > 85: const ElfW(Rel) *relative = r; > 86: r += nrelative; > [...] > 111: for (; relative < r; ++relative) > 112: DO_ELF_MACHINE_REL_RELATIVE (map, l_addr, relative); > > gdb claims it crashes at line 111. It does indeed crash there, although on line 112 not line 111. DO_ELF_MACHINE_REL_RELATIVE is defined to be elf_machine_rel_relative, which in this case has been defined to elf_machine_rela_relative, which is an always-inline function that will just perform some calculations and a single assignment to the relocation address. The reason it crashes is that libx264 has R_SPARC_RELATIVE relocations which are not 8-byte aligned. This is because ld incorrectly converts some R_SPARC_32 relocations into R_SPARC_RELATIVE ones, which is only valid for 32-bit Sparc. I have attached a patch which seems to fix this particular case; recompiling libx264, linking main.c with it and running the resulting main no longer leads to a bus error, and terminates with exit code 0. James
Attachment:
signature.asc
Description: PGP signature