From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Huig=DJ=gmail.com=wzssyqa@sourceware.org>
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634])
	by sourceware.org (Postfix) with ESMTPS id 117023858D28;
	Sun, 23 Jul 2023 04:52:31 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 117023858D28
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com
Received: by mail-pl1-x634.google.com with SMTP id d9443c01a7336-1b8a44ee159so19578955ad.3;
        Sat, 22 Jul 2023 21:52:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20221208; t=1690087950; x=1690692750;
        h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
         :date:message-id:reply-to;
        bh=Lh7uPN5p6qlEj/67H3AkDvdxcVV6MNL6bztppJe0Mqk=;
        b=iLTi8y7El3NFrAxtbHxoQO9r7zEnzJQJF5B0nIEJuRvSLOx2M9q4G7zeG98alGvSgS
         /qezle+C8xU9lvXCLjsYmbSO2SR9ZilA5T1q5frPYyXvXc19EgYkEcn5kCNKtQ8XsFSg
         /Ob7SATYQNyRohlgTNdzaFOSokXSM56CMFWOIS3lZ6CleBsnt2jSQdmyDCfVp4SCJJmh
         TrfPB1GbDlSNHyqiWn6gclWGN0g9FF+eMhpbHRqo7Y59nWjDzSLY30a56LH/6iD6yo5s
         N/6rY2gxFMpxzBQQt03KCyJ+OgtGB92j4wOHI0ipidylLlD9UWQEimzt2vdsKM8cx4ZS
         CS+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20221208; t=1690087950; x=1690692750;
        h=to:subject:message-id:date:from:mime-version:x-gm-message-state
         :from:to:cc:subject:date:message-id:reply-to;
        bh=Lh7uPN5p6qlEj/67H3AkDvdxcVV6MNL6bztppJe0Mqk=;
        b=RRLLxk5dhy3ghldy27ftIESzV9eDG4cOfVuiTYa1PWLyxovNh264A/Z9bEWC9TUkEB
         +NyJQvmozJklsHD2x0QcD+rdLUjARYVs1JKsCAYXgET7rC0AemP+mb0SJb61HtrVRrf7
         iYO/XA6rXNqpskvLJgLGMOGjqbt+6kM3E7ABIGJJYwOmYVWnRFpsqCfvxLfErhXj9vCr
         4LsnXX2A5wY8ZJkmVYyMMV9vW35q4rsBgE5z9avx6J9jL7EkOEctk+EdCzX9UupvKIig
         qKxrJ8hYEkD1YezigvAV4sIrLw/lskHuilR1+OxZIQDc0h3GvJg295y5Mu0fFJg0WVcf
         R9Dw==
X-Gm-Message-State: ABy/qLbflW5pmEy/LO7j+t2ht33aGQ678kRX3cugusfTEThJT+ZvWX36
	+VQJ1qUik0+sbCZtjtyBB3T144bL7s5XRISQQe7UARcT/iEpmzrO
X-Google-Smtp-Source: APBJJlFD9Oj46OJB7I4S5Vj9dSZ3eW14MA3CDgPD9JUk8hGqN2qWCbFeLlDyfKI7XqQB3Jbtwih4YiFq9bEQ+DMww7M=
X-Received: by 2002:a17:903:41d1:b0:1b8:88ae:811e with SMTP id
 u17-20020a17090341d100b001b888ae811emr7137899ple.29.1690087949890; Sat, 22
 Jul 2023 21:52:29 -0700 (PDT)
MIME-Version: 1.0
From: YunQiang Su <wzssyqa@gmail.com>
Date: Sun, 23 Jul 2023 12:52:18 +0800
Message-ID: <CAKcpw6UjNkw8Z6m0=_w1NhWpap1WhjrVUzyRKc+J4bynB3zhcA@mail.gmail.com>
Subject: The definition of ELF64_MIPS_R_TYPE is ambiguous
To: binutils <binutils@sourceware.org>, Libc-alpha <libc-alpha@sourceware.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <binutils.sourceware.org>

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.