在 2023/5/22 05:13, Mark Wielaard 写道: > Hi Ying, > > On Tue, May 16, 2023 at 02:38:45PM +0800, Ying Huang wrote: >> 在 2023/5/9 23:15, Mark Wielaard 写道: >>> On Tue, 2023-04-11 at 16:12 +0800, Ying Huang wrote: >>>> In mips64 little-endian, r_info consists of four byte fields(contains >>>> three reloc types) and a 32-bit symbol index. In order to adapt >>>> GELF_R_SYM and GELF_R_TYPE, need convert raw data to get correct symbol >>>> index and type. >>> Is there a spec that describes this? >> >> >> references: >> >> https://www.linux-mips.org/pub/linux/mips/doc/ABI/elf64-2.4.pdf >> >> Page40 && Page41 > Thanks. Interesting. If possible please include this URL in a comment. OK. > >>> I see you adjusted elf.h to include: >>> >>> +#define ELF64_MIPS_R_TYPE(i) ((i) & 0xff) >>> +#define ELF64_MIPS_R_TYPE2(i) (((i) >> 8) & 0xff) >>> +#define ELF64_MIPS_R_TYPE3(i) (((i) >> 16) & 0xff) >>> >>> And various new relocation types for MIPS variants. >>> Our elf.h comes from the glibc project. Have you also submitted these >>> changes to libc-al...@sourceware.org ? >> Has submitted. >> >> https://sourceware.org/pipermail/libc-alpha/2023-May/148026.html >> >> https://sourceware.org/pipermail/libc-alpha/2023-May/148112.html > Thanks. We'll sync them as soon as v3 lands. > >> Has tested on big/little endian machine with big/little endian >> ELF file, all were OK. > Could you post those ELF files somewhere? > Maybe we can add some as test files? The ELF files I used were "src/strip.o" which were generated on big/little endian machine.
root@debian-sid-mipsbe:~# readelf -h strip.o ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: REL (Relocatable file) Machine: MIPS R3000 Version: 0x1 Entry point address: 0x0 Start of program headers: 0 (bytes into file) Start of section headers: 426696 (bytes into file) Flags: 0x80000007, noreorder, pic, cpic, mips64r2 Size of this header: 64 (bytes) Size of program headers: 0 (bytes) Number of program headers: 0 Size of section headers: 64 (bytes) Number of section headers: 41 Section header string table index: 40 root@debian-sid-mipsbe:~# readelf -h elfutils_debug/src/strip.o ELF Header: Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, big endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: REL (Relocatable file) Machine: MIPS R3000 Version: 0x1 Entry point address: 0x0 Start of program headers: 0 (bytes into file) Start of section headers: 215248 (bytes into file) Flags: 0x70001007, noreorder, pic, cpic, o32, mips32r2 Size of this header: 52 (bytes) Size of program headers: 0 (bytes) Number of program headers: 0 Size of section headers: 40 (bytes) Number of section headers: 40 Section header string table index: 39 root@debian-sid-mipsbe:~# >>> It feels like this is in the wrong place and doesn't take into account >>> whether the program itself is running on a big or little endian >>> machine. >>> >>> Maybe I am misunderstanding why this conversion is needed always. But I >>> would have expected a specific conversion function for MIPS for >>> ELF_T_REL and/or ELF_T_RELA (which are currently generic). >> 1.Considering that some people directly use the original data instead of >> the interface function gelf_getrela; >> >> 2.Because there is only one parameter, so can not modify the macro >> ELF64_R_TYPE； >> >> 3.If the mips interface function is added, other packages using libelf >> will not be compatible with mips, and the place where gelf_getrela is used >> need be modified. >> >> Where do you think is the most suitable place to do mips conversion? > So for the convert_data case in elf_getdata.c I would expect a special > conversion function being defined for ELF_T_REL and ELF_T_RELA. This > normally comes from __elf_xfctstom. I realize now that cannot easily > take an Elf of machine type. But I would expect to have the conversion > be done by a new function that can be assigned to fp in convert_data: > > /* Get the conversion function. */ > fp = __elf_xfctstom[eclass - 1][type]; Maybe I can create a new function named "convert_data_for_mips" and contained the code that added in convert_data? > > I still don't fully understand the need of the code in elf_update. I > assume that is needed in case the file was used with ELF_C_RDWR_MMAP? > > Cheers, > > Mark Because we convert the relocation data for mips64el in elf_getdata.c, eg src/strip, and when we write elf to file, need confirm the relocation data is in original order bits. When file use ELF_C_RDWR_MMAP, only impact whether malloc data_base in convert_data. Thanks, Ying
