The definition of ELF64_MIPS_R_TYPE is ambiguous

The definition of ELF64_MIPS_R_TYPE is ambiguous

[YunQiang Su]

With some search of the definition of ELF64_MIPS_R_TYPE macro, we find
that they are defined differently between projects.
http://codesearch.debian.net/search?q=ELF64_MIPS_R_TYPE

1. In binutils-gdb/include/elf/mips.h, it is defined as:
    #define ELF64_MIPS_R_TYPE(i) ((i) & 0xff)

    newlib/include/elf/elf.h, linux/scripts/mod/modpost.h, libiberty,
are using a similar definition.

2. In glibc/sysdeps/mips/ldsodefs.h, it is defined as:
    #define ELF64_MIPS_R_TYPE(i) \
  (((_Elf64_Mips_R_Info_union)(i)).r_info_fields.r_type1 \
   | ((Elf32_Word)(__extension__ (_Elf64_Mips_R_Info_union)(i) \
                   ).r_info_fields.r_type2 << 8) \
   | ((Elf32_Word)(__extension__ (_Elf64_Mips_R_Info_union)(i) \
                   ).r_info_fields.r_type3 << 16) \
   | ((Elf32_Word)(__extension__ (_Elf64_Mips_R_Info_union)(i) \
                  ).r_info_fields.r_ssym << 24))

   uclibc/ldso/ldso/mips/dl-sysdep.h is using a similar definition.


I think that we should sync all of them to protect people from confusion.
We are lucky enough that ELF64_MIPS_R_TYPE is not used widely by normal APPs.
So it gives us the chance to make it sync between projects.
Any suggestions?

For myself, I prefer the way of glibc/uclibc:
1. Define ELF64_MIPS_R_TYPE1 for the lowest byte of r_info.
2. Define ELF64_MIPS_R_TYPE for full r_info.

Re: The definition of ELF64_MIPS_R_TYPE is ambiguous

[Andreas Schwab]

On Jul 23 2023, YunQiang Su via Libc-alpha wrote:

> I think that we should sync all of them to protect people from confusion.
> We are lucky enough that ELF64_MIPS_R_TYPE is not used widely by normal APPs.
> So it gives us the chance to make it sync between projects.

Is the macro defined by the ELF psABI?

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: The definition of ELF64_MIPS_R_TYPE is ambiguous

[YunQiang Su]

Andreas Schwab <schwab@linux-m68k.org> 于2023年7月23日周日 14:51写道：
>
> On Jul 23 2023, YunQiang Su via Libc-alpha wrote:
>
> > I think that we should sync all of them to protect people from confusion.
> > We are lucky enough that ELF64_MIPS_R_TYPE is not used widely by normal APPs.
> > So it gives us the chance to make it sync between projects.
>
> Is the macro defined by the ELF psABI?
>

As best as I know, the answer is no. (Correct me if anybody know about it.)

> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."



-- 
YunQiang Su

Re: The definition of ELF64_MIPS_R_TYPE is ambiguous

[Andreas Schwab]

On Jul 23 2023, YunQiang Su wrote:

> Andreas Schwab <schwab@linux-m68k.org> 于2023年7月23日周日 14:51写道：
>>
>> On Jul 23 2023, YunQiang Su via Libc-alpha wrote:
>>
>> > I think that we should sync all of them to protect people from confusion.
>> > We are lucky enough that ELF64_MIPS_R_TYPE is not used widely by normal APPs.
>> > So it gives us the chance to make it sync between projects.
>>
>> Is the macro defined by the ELF psABI?
>>
>
> As best as I know, the answer is no. (Correct me if anybody know about it.)

Then it should not be defined in any shared header related to ELF ABI
definitions, especially not in glibc's elf.h.  It should remain private
to each project.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: The definition of ELF64_MIPS_R_TYPE is ambiguous

[Maciej W. Rozycki]

On Sun, 23 Jul 2023, Andreas Schwab wrote:

> >> > I think that we should sync all of them to protect people from confusion.
> >> > We are lucky enough that ELF64_MIPS_R_TYPE is not used widely by normal APPs.
> >> > So it gives us the chance to make it sync between projects.
> >>
> >> Is the macro defined by the ELF psABI?
> >>
> >
> > As best as I know, the answer is no. (Correct me if anybody know about it.)
> 
> Then it should not be defined in any shared header related to ELF ABI
> definitions, especially not in glibc's elf.h.  It should remain private
> to each project.

 FWIW the 64-bit MIPS psABI[1] has instead redefined Elf64_Rela and 
Elf64_Rel structures (previously supplied by SPARC International with 
their 64-bit extensions to the original 32-bit ELF gABI):

typedef struct
{
  Elf64_Addr	r_offset;
  Elf64_Word	r_sym;
  Elf64_Byte	r_ssym;
  Elf64_Byte	r_type3;
  Elf64_Byte	r_type2;
  Elf64_Byte	r_type;
} Elf64_Rel;

typedef struct
{
  Elf64_Addr	r_offset;
  Elf64_Word	r_sym;
  Elf64_Byte	r_ssym;
  Elf64_Byte	r_type3;
  Elf64_Byte	r_type2;
  Elf64_Byte	r_type;
  Elf64_Sxword	r_addend;
} Elf64_Rela;

(transcribed from a language-agnostic representation).  I'm not sure if it 
can be factored in anyhow in <elf.h>.

 Observe the endianness-independent layout of the five fields following 
`r_offset', which makes macros such as ELF64_MIPS_R_TYPE unsuitable for 
use in the little-endian case with unprocessed `r_info' field as defined 
by 64-bit ELF gABI.

[1] "64-bit ELF Object File Specification", Draft Version 2.5, MIPS 
    Technologies / Silicon Graphics Computer Systems, Document Number 
    007-4658-001, Table 29 "Relocation Operation (Elf64_Rel, Elf64_Rela)", 
    p. 40

  Maciej