From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-92935-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 36959 invoked by alias); 6 Jun 2018 15:53:34 -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 36247 invoked by uid 89); 6 Jun 2018 15:53:32 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=
X-HELO: mx1.redhat.com
Subject: Re: RFC: x86: Fall back to lazy binding for unrelocated IFUNC symbol
 [BZ #23240]
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Carlos O'Donell <carlos@redhat.com>,
 GNU C Library <libc-alpha@sourceware.org>
References: <20180526135209.GA23818@intel.com>
 <fbaa5916-fc89-0ab9-72ed-883a408eaad4@redhat.com>
 <CAMe9rOrKtM2t3khHZonNw_xpZ22Nj2BU1A-6_7eAa6nNaQGDDA@mail.gmail.com>
 <a34107c3-880e-c40b-98b2-8026e9e29acf@redhat.com>
 <d476f562-1f99-3817-7b86-788e3540a42a@redhat.com>
 <CAMe9rOoKECiA-0ZHFazLzzBtvHVmCdMzYaBfqsJwh0q2Qch07w@mail.gmail.com>
 <c311c003-8b33-6d40-26ac-062a9f3e79e5@redhat.com>
 <363168df-c501-9d28-446b-34ee33a11611@redhat.com>
 <CAMe9rOo47VqTMhqC2=52n-Ws92VGQPHeHbyDom9VqGXa+nNCOg@mail.gmail.com>
 <66949fa3-5ebd-f094-3755-75d524f1b36a@redhat.com>
 <CAMe9rOpcyGC2GmoNUjTEXtn9bL3wwTwQNMYQ6otd3axYOcPT=w@mail.gmail.com>
From: Florian Weimer <fweimer@redhat.com>
Message-ID: <df066266-49cf-2c37-2fde-02ca570e2e49@redhat.com>
Date: Wed, 06 Jun 2018 15: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: <CAMe9rOpcyGC2GmoNUjTEXtn9bL3wwTwQNMYQ6otd3axYOcPT=w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-SW-Source: 2018-06/txt/msg00089.txt.bz2

On 06/06/2018 05:38 PM, H.J. Lu wrote:
> I pushed hjl/pr23240/fw, which is fw/bug21242 + tests for [BZ #23176] and
> [BZ #23240].
> 
> 1. On x86-64:
> 
> FAIL: elf/reldep6a

The crash happens because “weak” is undefined in reldep6mod1.so.

The “weak” function is defined in reldep6mod4.so.  But reldep6mod1.so is 
loaded before reldep6mod4.so:

      14289:     calling init: 
/home/fweimer/src/gnu/glibc/build/elf/reldep6mod1.so
…
      14289:     opening 
file=/home/fweimer/src/gnu/glibc/build/elf/reldep6mod4.so [0]; 
direct_opencount=1
      14289:
      14289:     binding file 
/home/fweimer/src/gnu/glibc/build/elf/reldep6mod4.so [0] to 
/home/fweimer/src/gnu/glibc/build/elf/reldep6mod1.so [0]: normal symbol 
`baz'

I think this is simply invalid.  I think that if you had a “weak == 
NULL” check in reldep6mod1.so, it would be false even after loading 
reldep6mod4.so because the address is not lazily bound.

Is this derived from the X server use case, where they load additional 
DSOs which provide definitions of functions which are lazily bound? 
That's just not compatible with BIND_NOW, and I don't see a compelling 
reason why it should be.  If it's just about fixing X, then we need to 
fix X, and not enhance the dynamic linker.

> 2. On i686:
> 
> FAIL: elf/ifuncpreload1
> FAIL: elf/reldep6a

There's no delayed processing for i686 yet.  I wanted to get consensus 
on the overall approach first.

Thanks,
Florian