From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59715 invoked by alias); 16 Oct 2019 11:15:32 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 59705 invoked by uid 89); 16 Oct 2019 11:15:31 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=fell X-HELO: mx1.redhat.com Subject: Re: [PATCH] elf: Always set l in _dl_init_paths (Bug 23462). To: Florian Weimer Cc: libc-alpha References: <87d0ex6mo6.fsf@oldenburg2.str.redhat.com> From: Carlos O'Donell Message-ID: <8b35f8b3-1d61-dce0-f59a-42c104449a44@redhat.com> Date: Wed, 16 Oct 2019 11:15:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <87d0ex6mo6.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-10/txt/msg00481.txt.bz2 On 10/16/19 5:54 AM, Florian Weimer wrote: > * Carlos O'Donell: > >> diff --git a/elf/dl-load.c b/elf/dl-load.c >> index 438793e53d..903f8af13a 100644 >> --- a/elf/dl-load.c >> +++ b/elf/dl-load.c >> @@ -748,50 +748,47 @@ _dl_init_paths (const char *llp) >> max_dirnamelen = SYSTEM_DIRS_MAX_LEN; >> *aelem = NULL; >> >> -#ifdef SHARED >> - /* This points to the map of the main object. */ >> + /* This points to the map of the main object. It is always non-NULL >> + since we have purposely made the dynamic and static cases look the >> + same. */ >> l = GL(dl_ns)[LM_ID_BASE]._ns_loaded; >> - if (l != NULL) >> + assert (l->l_type != lt_loaded); >> + >> + if (l->l_info[DT_RUNPATH]) >> + { >> + /* Allocate room for the search path and fill in information >> + from RUNPATH. */ >> + decompose_rpath (&l->l_runpath_dirs, >> + (const void *) (D_PTR (l, l_info[DT_STRTAB]) >> + + l->l_info[DT_RUNPATH]->d_un.d_val), >> + l, "RUNPATH"); >> + /* During rtld init the memory is allocated by the stub malloc, >> + prevent any attempt to free it by the normal malloc. */ >> + l->l_runpath_dirs.malloced = 0; >> + >> + /* The RPATH is ignored. */ >> + l->l_rpath_dirs.dirs = (void *) -1; >> + } > > Does this change enable DT_RUNPATH/DT_RPATH for statically linked > binaries? Should that receive a NEWS entry and a test? It does enable DT_RUNPATH/DT_RPATH for statically linked binaries, and we should probably add a test for that? This is not a consequence I actively thought too deeply about because it fell under the "make static binaries behave like dynamic binaries" which was within our design goals. However, now that you mention it, it will be a semantic change if anyone has ever built a static binary with DT_RUNPATH/DT_RPATH, the behaviour will now be changed. Let me add a NEWS entry for this. If you think the semantic change here is wrong, please call that out. -- Cheers, Carlos.