From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id 232F939450C6 for ; Mon, 9 Mar 2020 14:54:35 +0000 (GMT) Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jBJnd-0008CF-LF; Mon, 09 Mar 2020 14:54:33 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1jBJm5-0008Lq-20; Mon, 09 Mar 2020 15:52:57 +0100 From: Florian Weimer To: Kaylee Blake Cc: binutils@sourceware.org Subject: Re: RFC: [PATCH] ELF: Don't require section header on ELF objects References: <20200308175947.GA911529@gmail.com> <87y2sac5er.fsf@mid.deneb.enyo.de> <79bc289f-9202-9aff-61c3-92c7190d2f7d@gmail.com> <875zfdad9j.fsf@mid.deneb.enyo.de> <36183da0-ed0c-13bf-2cb3-bd004e8d46f9@gmail.com> <87y2s98y94.fsf@mid.deneb.enyo.de> <87tv2x8xmy.fsf@mid.deneb.enyo.de> Date: Mon, 09 Mar 2020 15:52:57 +0100 In-Reply-To: (Kaylee Blake's message of "Tue, 10 Mar 2020 00:15:27 +1030") Message-ID: <87lfo98trq.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 14:54:36 -0000 * Kaylee Blake: > On 9/3/20 11:59 pm, Florian Weimer wrote: >> * Kaylee Blake: >> >>>> I think that's conceptually the wrong thing to do for ELF, sorry. If >>>> there is no section header, the object should be unlinkable. The >>>> linker should not use the dynamic segment to locate the symbol >>>> information, only the dynamic section (in case the link ABI and >>>> run-time ABI are different). >>> >>> I'm confused by your comment about link and run-time ABIs differing; >>> surely if the ABI at runtime differs from the ABI at link time, you are >>> just going to crash at runtime? >> >> No, the typical application are fewer symbols in the DSO at link time >> than at load time, for example for linking against an older version of >> glibc than is installed on the system. > > How is that being done? libc.so is replaced with something that contains a stub library which only exports the intended symbols, at the right versions. If I recall correctly, some enterprise database products are linked using ld against such a stub library upon installation. It's a bit weird for sure, but it's what people do. > On my machine, the symbols in glibc found through the section header > are identical to the ones found through the dynamic array, except > that some of the latter are missing symbol versions, which I think > is due to this patch not looking them up? Ah, didn't know that the compat symbols (those with @ symbol versions instead of @@ synbol versions) are not present in .symtab. That makes sense, given that they are not supposed to be linked against for new binaries. We should definitely keep hiding symbols which lack a default symbol version.