The definition of ELF64_MIPS_R_TYPE is ambiguous

[YunQiang Su <wzssyqa@gmail.com>]

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.