From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-93944-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 117842 invoked by alias); 3 Jul 2018 13:53:07 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 117820 invoked by uid 89); 3 Jul 2018 13:53:06 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=identification, bumping, HX-HELO:sk:mail-qk
X-HELO: mail-qk0-f194.google.com
Return-Path: <carlos@redhat.com>
Subject: Re: [PATCH 2/2] libc-abis: Define ABSOLUTE ABI [BZ #19818][BZ #23307]
To: "Maciej W. Rozycki" <macro@mips.com>, libc-alpha@sourceware.org
Cc: Florian Weimer <fweimer@redhat.com>, Alan Modra <amodra@gmail.com>
References: <alpine.DEB.2.00.1806181533590.20622@tp.orcam.me.uk>
 <alpine.DEB.2.00.1806181810570.20622@tp.orcam.me.uk>
 <87sh5a38tz.fsf@mid.deneb.enyo.de>
 <alpine.DEB.2.00.1806261348560.20622@tp.orcam.me.uk>
 <d1ee54d8-9491-28cb-3fcf-b13408d47b6a@redhat.com>
 <alpine.DEB.2.00.1806280905490.20622@tp.orcam.me.uk>
 <d6680b9a-2afe-7801-c923-0bdceb736950@redhat.com>
 <alpine.DEB.2.00.1806281516050.20622@tp.orcam.me.uk>
 <alpine.DEB.2.00.1806291721220.20622@tp.orcam.me.uk>
From: Carlos O'Donell <carlos@redhat.com>
Openpgp: preference=signencrypt
Message-ID: <87b6fb82-09cf-e79c-79a4-281a0a297a64@redhat.com>
Date: Tue, 03 Jul 2018 13:53:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.00.1806291721220.20622@tp.orcam.me.uk>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-SW-Source: 2018-07/txt/msg00059.txt.bz2

On 06/29/2018 12:29 PM, Maciej W. Rozycki wrote:
> On Thu, 28 Jun 2018, Maciej W. Rozycki wrote:
> 
>>>> +  /* Mark that we need support for absolute symbols in the dynamic loader.
>>>> */
>>>> +  if (htab != NULL && htab->use_absolute_zero)
>>>> +    i_ehdrp->e_ident[EI_ABIVERSION] = MIPS_LIBC_ABI_ABSOLUTE;
>>>> +
>>>>     _bfd_elf_post_process_headers (abfd, link_info);
>>>>   }
>>>>   and then `htab->use_absolute_zero' will be TRUE iff a GOT relocation has
>>>> been calculated to actually refer to a specially-created absolute symbol
>>>> used to address the issue covered by binutils PR ld/21375.
>>>>
>>>>   The flag will be FALSE if code has been relaxed to avoid referring the
>>>> GOT (by using immediate zero instead), in which case no absolute symbol
>>>> will have been specially created.
>>>>
>>>>   Does this explanation clear your concern?
>>>
>>> Yes, I think this is okay then.
>>
>>  Great!
> 
>  Any further input?  Have we reached consensus?
> 
>  If so, then I think a NEWS entry will be due, such as:
> 
> * The maximum libc ABI supported has been increased to reflect absolute
>   symbol support.  This can be used by the static linker in the ELF file
>   header's EI_ABIVERSION field to indicate such support is required.

Suggest:

* The GNU C Library now has correct support for ABSOLUTE symbols
  (SHN_ABS-relative symbols).  Previously such ABSOLUTE symbols were relocated
  inconsistently or wrongly in some cases.  The GNU linker has been enhanced to
  fix this issue, but it must communicate these newer semantics to the dynamic
  loader by setting the ELF file's identification (EI_ABIVERSION field) to 
  indicate such support is required.
 
> which I will include in the actual commit.

This looks good to me.

I don't see an easy way around this problem.

I think bumping EI_ABIVERSION is the best cost/value solution there.

-- 
Cheers,
Carlos.