On Sat, Aug 08, 2015 at 11:47:04AM +0200, Mark Wielaard wrote: > On Sat, Aug 08, 2015 at 10:58:15AM +0200, Kai Wasserbäch wrote: > > And there *IS* a difference vs. your output: for you the relocations in > > 794488_elfs/libelf1/dump.elf.J4EnbO look fine, for me the second relocation > > is > > botched with libelf1 while it works with libelfg0. > > > > libelf1: > > relocations: 2 > > 0: 10, SCRATCH_RSRC_DWORD1 > > 1: 200000081, > > > > libelfg0: > > relocations: 2 > > 0: 10, SCRATCH_RSRC_DWORD1 > > 1: 2c, SCRATCH_RSRC_DWORD0 > > Awesome. That should explain why the application of that relocation > crashes and burns. Odd I couldn't replicate locally against elfutils > libelf 0.163. It might be some subtle compiler code generation issue. > Or maybe debian applies a patch that isn't upstream? > Yep! > https://sources.debian.net/src/elfutils/0.163-4/debian/patches/0003-Add-mips-n64-relocation-format-hack.patch/?hl=34#L34 > > Note how that replaces the cast and sizeof Elf64_Rel with Elf64_Rela > in the memcpy. Those are not the same size! > > Could someone rebuild the debian package without that patch applied > (or correctly replace the wrong Elf64_Rela with Elf64_rel) and see if > that helps?
I'm guessing that's only for the gelf_getrel.c file and that the change in gelf_getrela.c is correct? Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
