From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=mGkT=DY=orcam.me.uk=macro@sourceware.org>
Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34])
	by sourceware.org (Postfix) with ESMTP id 34D523858D28;
	Mon,  7 Aug 2023 11:09:38 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 34D523858D28
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk
Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk
Received: by angie.orcam.me.uk (Postfix, from userid 500)
	id 057FC9200B3; Mon,  7 Aug 2023 13:09:36 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by angie.orcam.me.uk (Postfix) with ESMTP id F3B1F92009E;
	Mon,  7 Aug 2023 12:09:36 +0100 (BST)
Date: Mon, 7 Aug 2023 12:09:36 +0100 (BST)
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Andreas Schwab <schwab@linux-m68k.org>
cc: YunQiang Su <wzssyqa@gmail.com>, 
    YunQiang Su via Libc-alpha <libc-alpha@sourceware.org>, 
    binutils <binutils@sourceware.org>
Subject: Re: The definition of ELF64_MIPS_R_TYPE is ambiguous
In-Reply-To: <87bkg3jdt9.fsf@linux-m68k.org>
Message-ID: <alpine.DEB.2.21.2308062102370.38537@angie.orcam.me.uk>
References: <CAKcpw6UjNkw8Z6m0=_w1NhWpap1WhjrVUzyRKc+J4bynB3zhcA@mail.gmail.com> <87fs5fjf1w.fsf@linux-m68k.org> <CAKcpw6X171OeT3VMJ0GiXJ5frrNYnPFCymXr-vVG=6wPrj=NyQ@mail.gmail.com> <87bkg3jdt9.fsf@linux-m68k.org>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-1163.2 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <libc-alpha.sourceware.org>

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