From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x244.google.com (mail-oi1-x244.google.com [IPv6:2607:f8b0:4864:20::244]) by server2.sourceware.org (Postfix) with ESMTPS id 694423949F15 for ; Mon, 9 Mar 2020 13:54:41 +0000 (GMT) Received: by mail-oi1-x244.google.com with SMTP id y71so4820882oia.7 for ; Mon, 09 Mar 2020 06:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pRW2I+WW3RVX7m1bfqaaTLvYiDV2JW1uo1H+hAJJm6Y=; b=DZOFtZHXPWI2+DkMS2lmJd2w/jcJUVoXnG2V9G1JYer3lbM6XIi218Iev11adJHZVV iNISp4070SzKKtHZguKOiNwDyqiTCBUDNlIAbFrLT0aJSRX/+Hp9QATjAfJN2vn/nBVt FYmk57StcQpAfT5UD7yrq9DP+GwNBQpmxPzspVEXyF22DMI2DE77/Ylh/wmMzzShrHW/ ARmsUaYcf8Js5olEHE7z+NDCsiecsUnofS91FlWaZSakY0sYp8fbf4WpR27AwPfmTU5q bMJeKZJQTdH6/jVWTNvxC4imeMUyh+AMwUhlT7Vv1zmtYKt23Zp8CG+YQIHfSolD8D9F bSWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pRW2I+WW3RVX7m1bfqaaTLvYiDV2JW1uo1H+hAJJm6Y=; b=h5ycuw5dEU1kTxVqibwV7MCKGHS8pCkNOqUhG2bSZ6JAOAAdYQV5i/Qnvus+Q0bdrA anYgYTVq6pbvUDOuJomYCoQ4xu3tXjKghVuZzvUWStxtf/lGzwcsSLwRuwhOhvMtwzaI HmbuWO2PeASJ6lRID2iFCBC+auGZWmI6j7NxKk8zNIi5Pt84W7n9p+G/xRZxB5EvFtvo utOKIOSDqsXHSZFWIM+PzFXtaGhr5ZgmvBERPr8+kZusBGPA3rrxC6asTn3LcbJr9OS3 qgj+DxX5ZwW91d8M8FiqtdiQ5Y3UH1B66PcojMViaotfji/NqwfgcMVtRwE/q+unZIH/ 2KvA== X-Gm-Message-State: ANhLgQ2djLYAVv2RHf0Yw2kQDu6qDnVRvv0eCAM97/BxiVj5SNooCSu7 mrOB2+M45h0EIDhsSOTEqeOdz+V6ByOFfC4jVo3cv1pH X-Google-Smtp-Source: ADFU+vutd81PiEJKgiL63njqu4GnX57dhv//c5LNEI54oTWFSY1zxC7JGT4uO44oxQ6gmSUz6/Fz6oBvS7HQWvQZCYI= X-Received: by 2002:aca:8ce:: with SMTP id 197mr1763766oii.35.1583762080773; Mon, 09 Mar 2020 06:54:40 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: "H.J. Lu" Date: Mon, 9 Mar 2020 06:54:04 -0700 Message-ID: Subject: Re: RFC: [PATCH] ELF: Don't require section header on ELF objects To: Kaylee Blake Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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 13:54:42 -0000 On Mon, Mar 9, 2020 at 6:46 AM Kaylee Blake wrote: > > 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? 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? (I'm > not actually sure if this patch does that or not). > Symbol versioning is a real problem. We need to reconstruct all dynamic symbol info from PT_DYNAMIC segment. I am running into a wrong output problem on i386. I am leaning toward Florian's suggestion to only add --remove-section-header and -z nosectionheader without reconstructing dynamic symbol info from PT_DYNAMIC segment. -- H.J.