Hi,

在 2023/5/9 23:15, Mark Wielaard 写道:
> Hi,
>
> On Tue, 2023-04-11 at 16:12 +0800, Ying Huang wrote:
>> From: Ying Huang <ying.huang@oss.cipunited.com>
>>
>> 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

>
> 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-alpha@sourceware.org ?
    Has submitted.

    https://sourceware.org/pipermail/libc-alpha/2023-May/148026.html

    https://sourceware.org/pipermail/libc-alpha/2023-May/148112.html

>
>>   libelf/elf_getdata.c: Some eu-utils use read-mmap method to map file,
>> so we need to malloc and memcpy raw data to avoid segment fault. After
>> modification, the correct value are saved in the malloced memory not in
>> process address space.
> Where do these segfaults show up?

>
>>   libelf/elf_updata.c: Because we converted the relocation info in mips
>> order when we call elf_getdata.c, so we need to convert the modified data
>> in original order bits before writing the data to the file.
    Has tested on big/little endian machine with big/little endian ELF file, all were OK.
> 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).
>
> Cheers,
>
> Mark
    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?

Thanks,

Ying