From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=OiG5=DO=orcam.me.uk=macro@sourceware.org>
Received: from angie.orcam.me.uk (angie.orcam.me.uk [IPv6:2001:4190:8020::34])
	by sourceware.org (Postfix) with ESMTP id 072E33858D1E
	for <binutils@sourceware.org>; Fri, 28 Jul 2023 06:56:40 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 072E33858D1E
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 6887892009C; Fri, 28 Jul 2023 08:56:39 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by angie.orcam.me.uk (Postfix) with ESMTP id 624A292009B;
	Fri, 28 Jul 2023 07:56:39 +0100 (BST)
Date: Fri, 28 Jul 2023 07:56:39 +0100 (BST)
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Jan Beulich <jbeulich@suse.com>
cc: Chenghua Xu <paul.hua.gm@gmail.com>, Binutils <binutils@sourceware.org>
Subject: Re: non-conformant ELF symbol table on MIPS?
In-Reply-To: <5a410132-b62f-b932-cb00-ee6ad0a3a99b@suse.com>
Message-ID: <alpine.DEB.2.21.2307280739510.10240@angie.orcam.me.uk>
References: <ce321476-4575-ba44-acd7-37ac1331e235@suse.com> <alpine.DEB.2.21.2307271717100.10240@angie.orcam.me.uk> <5a410132-b62f-b932-cb00-ee6ad0a3a99b@suse.com>
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=-3488.6 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: <binutils.sourceware.org>

On Fri, 28 Jul 2023, Jan Beulich wrote:

> >  There are two kinds of MIPS targets, ones that use the older IRIX symbol 
> > sorting rules and ones that use the newer "traditional" symbol sorting 
> > rules.  The IRIX symbol sorting rules mandate that section symbols precede 
> > all other symbols, see e.g. bfd/elf32-mips.c:mips_elf_sym_is_global.  
> 
> Along the lines of my reply to Ian: This still doesn't explain the
> behavior I observe. What you say is required could still be met without
> violating ELF rules.

 Yes, we could put section symbols first, then local ones, then external 
ones, and it was discussed many years ago, but it would require rather a 
heavy overhaul of generic parts of BFD.  Someone would have to do it just 
to handle a corner case, so it was concluded that it wouldn't be the best 
use of time, which would better be spent on something more important.

  Maciej