From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-74583-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 54980 invoked by alias); 9 Nov 2016 13:52:18 -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 54957 invoked by uid 89); 9 Nov 2016 13:52:17 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=ldl
X-HELO: mx1.redhat.com
Subject: Re: Pending fixes for all-ABIs builds
To: Andreas Schwab <schwab@suse.de>
References: <alpine.DEB.2.20.1611072319260.23588@digraph.polyomino.org.uk>
 <35e9c513-c873-3d7e-38e4-6aa14e9ef245@redhat.com>
 <alpine.DEB.2.20.1611082318390.23898@digraph.polyomino.org.uk>
 <fe75b5dd-3a6f-48a8-6cdc-5b54e1e1f01a@redhat.com>
 <mvmpom5c9i4.fsf@hawking.suse.de>
 <f8914907-a8ca-7e80-69a5-8248c27e1831@redhat.com>
 <mvm8tssdbtf.fsf@hawking.suse.de>
 <0a922f13-5130-51ca-fc73-6c003dbb20ce@redhat.com>
 <mvm4m3gdau3.fsf@hawking.suse.de>
Cc: Joseph Myers <joseph@codesourcery.com>, libc-alpha@sourceware.org
From: Florian Weimer <fweimer@redhat.com>
Message-ID: <b0abd80e-badc-0d6d-d6ea-9c9c10f81089@redhat.com>
Date: Wed, 09 Nov 2016 13:52:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <mvm4m3gdau3.fsf@hawking.suse.de>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2016-11/txt/msg00336.txt.bz2

On 11/09/2016 02:47 PM, Andreas Schwab wrote:
> On Nov 09 2016, Florian Weimer <fweimer@redhat.com> wrote:
>
>> On 11/09/2016 02:26 PM, Andreas Schwab wrote:
>>> On Nov 09 2016, Florian Weimer <fweimer@redhat.com> wrote:
>>>
>>>> On 11/09/2016 10:01 AM, Andreas Schwab wrote:
>>>>> On Nov 09 2016, Florian Weimer <fweimer@redhat.com> wrote:
>>>>>
>>>>>> Does this mean the dynamic linker starts with it's GOT pointer as NULL,
>>>>>> initializes that to point it to the malloc in elf/dl-minimal.c, and then,
>>>>>> once libc.so.6 is relocated updates its GOT pointer to point to the malloc
>>>>>> in libc.so.6?
>>>>>
>>>>> ld.so re-relocates itself after all static dependencies have been loaded
>>>>> and relocated.
>>>>
>>>> And even at this point, the code is used for future dynamic linking
>>>> operations?
>>>
>>> "The code" refers to what?
>>
>> The code in ld.so.
>
> If that's the only one.

Does this mean that if the application links against -ldl and invokes 
dlopen, a different dynamic linker implementation is used?  And the 
ld.so implementation is only used for internal dynamic loading, e.g. for 
NSS modules or gconv modules?

Thanks,
Florian