From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 56640 invoked by alias); 20 Feb 2020 11:51:40 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 56621 invoked by uid 89); 20 Feb 2020 11:51:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:f661f98, H*f:sk:f661f98 X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-ot1-f67.google.com Received: from mail-ot1-f67.google.com (HELO mail-ot1-f67.google.com) (209.85.210.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Feb 2020 11:51:38 +0000 Received: by mail-ot1-f67.google.com with SMTP id b3so2170384otp.4; Thu, 20 Feb 2020 03:51:38 -0800 (PST) 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=vNo/UeA25fdWhnSzN8lIzCaaPcX4snincJyfyWH9oBc=; b=gimQ3EGZ7t6EsCgMDtiAjrkP3SbNWAWMxa2rKkNyjh2tIadJ3ANbOjzbDSEjYsAt24 b+ra4TlmasY9ONMKSbhlHbiYbVP6Q5p+IKyfIsj4cORINpzYNb7zU+mvm4SVYAYo3YNR jWBt1zBy9NpGPX+1T530uucH2nvNlqstrPixkFZxcFAxE755Dkab2K58qxy69KfPhsZK hwaZtgM5jQVVF9+Pf6BhyDMlO1cqF8+ULkCt9z32hi1ZIfyU8/yEBiJmTLn4r5Gqf2SZ 11wPmlYTtEWx6qbAzwdrONTT+AXEMF3P5VAFDKPKM2CkBFtLICnTY7NGcP7SdXVgEwd8 orWg== 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=vNo/UeA25fdWhnSzN8lIzCaaPcX4snincJyfyWH9oBc=; b=HqOMcgD/lkJBJgJGB/9g4EeiTkSaUWCV0buLRQROZ7Ct1YGPfnPiGNuWIP2Ohg705m U8AzSIH8+ZBiksl/dMUjh6+oGqg1Gt1c5ZMaNMEuYh22mC46XCTNB96oGl19hdls/Mc5 wQNnnIM/+pDSTtNHC9jVhMuCRzV0jgcKt8sZB3bxDwju+2nchD35hWuo3X+AycEpVXfR UH8q3SPzA5jyd5QsWwO1SDPEvFnri2d1AUUqYXN+2dMcQxhT/J2e60rXZkyVBcG0M8fY XF6xFp1Tnt8GaFxZb/S0gwM/VprxTQqX1EE7oWzPBBAV24dMeKoLXnakdtmULNqzHcdY qinA== X-Gm-Message-State: APjAAAWP8Rxx/7lX6zJAV6S83vj6GRlaUfhbBTw650HP1noWDPH3/6dD ZvQaZbIxmwoeFB1YJ1JfFqZ+deeAnYNo5ZJX+Bg= X-Google-Smtp-Source: APXvYqzmT4euxfHm/fCp0bbsEwowaguu5ABmvHzeqIYM32q5EtiFKxmY1+Ou6S5UaxZkmDoYpB9TqU6ZU8rcx5I+tyA= X-Received: by 2002:a9d:4c14:: with SMTP id l20mr22945084otf.125.1582199496651; Thu, 20 Feb 2020 03:51:36 -0800 (PST) MIME-Version: 1.0 References: <20200219023120.gvr4ajolbjbqcfix@google.com> <6bf04476b559f11965b4474b500156e26949ffc2.camel@klomp.org> <20200219182701.vrtzwhgtpelmpaub@google.com> <2e29243995903cf2d52975543675f2b92fa1e201.camel@klomp.org> In-Reply-To: From: "H.J. Lu" Date: Wed, 01 Jan 2020 00:00:00 -0000 Message-ID: Subject: Re: binutils ld and new PT_GNU_PROPERTY segment To: Mark Wielaard Cc: Fangrui Song , Cary Coutant , "Zhang, Annita" , "Liu, Hongtao" , gnu-gabi , Binutils Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2020-q1/txt/msg00017.txt On Thu, Feb 20, 2020 at 1:37 AM Mark Wielaard wrote: > > Hi, > > On Wed, 2020-02-19 at 14:17 -0800, H.J. Lu wrote: > > On Wed, Feb 19, 2020 at 1:46 PM Mark Wielaard wrote: > > > This code isn't in the kernel yet. So either it gets changed to use the > > > existing scheme with gnu property notes found through PT_NOTE to work > > > with existing binaries. Then there is no need for PT_GNU_PROPERTY > > > headers. > > > > > > Or some future kernel will start using PT_GNU_PROPERTY headers to find > > > the gnu property notes. But that means it won't work with existing > > > binaries that do not have that header. So there is no backwards > > > compatibility anyway and we can define SHT_GNU_PROPERTY like above. > > > > > > So this actually seems the perfect time to make this decision. > > > > Binaries with .note.gnu.property section have been put into many > > OS releases. We must support them. > > OK. Then it is option 1. The kernel will need to support PT_NOTE for > parsing the properties, since such older binaries won't have a > PT_GNU_PROPERTY program header. Then we can simply get rid of > PT_GNU_PROPERTY since nobody uses it and all information is already > available through the PT_NOTE segment. > Kernel loader only checks ld.so and static executable. Re-link them with newer linker will get PT_GNU_PROPERTY. But ld.so needs to check PT_NOTE for older binaries. -- H.J.