Date: Fri, 09 Nov 2018 21:45:47 +0000 From: bugzilla-noreply@freebsd.org To: mips@FreeBSD.org Subject: [Bug 231790] objcopy: corrupts relocation entries in big-endian mips64 output when adjusting symbol indexes Message-ID: <bug-231790-27794-BjOvjM1PBW@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-231790-27794@https.bugs.freebsd.org/bugzilla/> References: <bug-231790-27794@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D231790 --- Comment #12 from commit-hook@freebsd.org --- A commit references this bug: Author: emaste Date: Fri Nov 9 21:45:44 UTC 2018 New revision: 340309 URL: https://svnweb.freebsd.org/changeset/base/340309 Log: Fix objcopy for little-endian MIPS64 objects. MFC r338478 (jhb): Fix objcopy for little-endian MIPS64 objects. MIPS64 does not store the 'r_info' field of a relocation table entry as a 64-bit value consisting of a 32-bit symbol index in the high 32 bits and a 32-bit type in the low 32 bits as on other architectures. Instead, the 64-bit 'r_info' field is really a 32-bit symbol index followed by four individual byte type fields. For big-endian MIPS64, treating this as a 64-bit integer happens to be compatible with the layout expected by other architectures (symbol index in upper 32-bits of resulting "native" 64-bit integer). However, for little-endian MIPS64 the parsed 64-bit integer contains the symbol index in the low 32 bits and the 4 individual byte type fields in the upper 32-bits (but as if the upper 32-bits were byte-swapped). To cope, add two helper routines in gelf_getrel.c to translate between the correct native 'r_info' value and the value obtained after the normal byte-swap translation. Use these routines in gelf_getrel(), gelf_getrela= (), gelf_update_rel(), and gelf_update_rela(). This fixes 'readelf -r' on little-endian MIPS64 objects which was previously decoding incorrect relocations as well as 'objcopy: invalid symbox index' warnings from objcopy when extracting debug symbols from kernel modules. Even with this fixed, objcopy was still crashing when trying to extract debug symbols from little-endian MIPS64 modules. The workaround in gelf_*rel*() depends on the current ELF object having a valid ELF header so that the 'e_machine' field can be compared against EM_MIPS. objcopy was parsing the relocation entries to possibly rewrite the 'r_info' fields in the update_relocs() function before writing the initial ELF header to the destination object file. Move the initial write of the ELF header earlier before copy_contents() so that update_relocs() uses the correct symbol index values. Note that this change should really go upstream. The binutils readelf source has a similar hack for MIPS64EL though I implemented this version from scratch using the MIPS64 ABI PDF as a reference. MFC r339083 (emaste): libelf: correct mips64el test to use ELF header libelf maintains two views of endianness: e_byteorder, and e_ident[EI_DATA] in the ELF header itself. e_byteorder is not always kept in sync, so use the ELF header endianness to test for mips64el. MFC r339473 (emaste): libelf: also test for 64-bit ELF in _libelf_is_mips= 64el Although _libelf_is_mips64el is only called in contexts where we've already checked that e_class is ELFCLASS64 but this may change in the future. Add a safety belt so that we don't access an invalid e_ehdr64 union member if it does. PR: 231790 Changes: _U stable/11/ stable/11/contrib/elftoolchain/elfcopy/main.c stable/11/contrib/elftoolchain/libelf/Makefile stable/11/contrib/elftoolchain/libelf/_libelf.h stable/11/contrib/elftoolchain/libelf/gelf_mips64el.c stable/11/contrib/elftoolchain/libelf/gelf_rel.c stable/11/contrib/elftoolchain/libelf/gelf_rela.c stable/11/sys/sys/param.h --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-231790-27794-BjOvjM1PBW>