From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57834 invoked by alias); 14 Oct 2016 16:15:50 -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 56808 invoked by uid 89); 14 Oct 2016 16:15:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=carlosredhatcom, carlos@redhat.com, coarse, happening X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-qk0-f176.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sYiF0Wai4O+rDICLP22Wl9EbgHY9+rrCKlUBsvoNjmU=; b=T3rMLAvqwuvHqXzULYUgJbBZQXPVJR9goNlLXP5DukqsHr6l0PjaSBCgP/7iqLQzAa RPIEGPzhNkP9CbwElLDeRgcUQUBHIaDdY/wYIzKaocci9jXNb5hajKatClZgIuoM07s9 6h0Y6ta0LKNgs0hQYuk3RP+9/un+P2P/cn1hgDZgHzZfPjZU/xCmNxcLa1yQGNUas6Jl CadUrlLAHwGrOHgMEj9gOwOVpGOqvnXl0OFnX+PfwANsG69trdzgyoALgZLIjt68tB3J 1sFTNvoCX9AyeMBUokVc/eu/YEuOoO0/qoTxXPftc+mIRBtoloqxRSpX3gC6Oa/wv0hs mozA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sYiF0Wai4O+rDICLP22Wl9EbgHY9+rrCKlUBsvoNjmU=; b=e36Cjh6x+DUx9yOs21arisf9uc/7z1NLRnjP4cDGUmKY/3cjcSdUPCsKEGpv4i0UfY iPMXciWhJN+HwEw15fyN38ivI//FwA6yQ6dqI3DmG9qBXpbf+vhDtdcbytvBPjcY0po+ hslre8x/X5RwQNpEc6AxgmpMx6Jmf61soT2bVi/h4fbwS1k2/B2l8l/Mqw+dH0GdH9OR ea1EFnCnxMOpNyE+PWFGQa8Aho7yNBpaC77ez4yJLbQWHxU1PY+ACbt2FNhQDwNtmJpE Qi3qqhnuZlqah2ifT490IooOHO9CcHbXTygLGpV5ghuC7jqa69bqhe6bBNbGJ1p/MvgY sAhA== X-Gm-Message-State: AA6/9RmjepfSXo1+eJG2vYZsZj6gzGD7K/ythMWrxqT9/2hR8fhL2wc9qkxCDWJb4VVEGEcehXDR8xHxSoHuXg== X-Received: by 10.55.5.21 with SMTP id 21mr14456526qkf.231.1476461746939; Fri, 14 Oct 2016 09:15:46 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <969fb6da-f13c-eb14-3e53-94a594384518@redhat.com> References: <969fb6da-f13c-eb14-3e53-94a594384518@redhat.com> From: "H.J. Lu" Date: Fri, 01 Jan 2016 00:00:00 -0000 Message-ID: Subject: Re: RFC: Program Properties To: "Carlos O'Donell" Cc: gnu-gabi@sourceware.org, Nick Clifton Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-q4/txt/msg00007.txt.bz2 On Thu, Oct 13, 2016 at 7:24 PM, Carlos O'Donell wrote: > On 10/12/2016 02:03 PM, H.J. Lu wrote: >> There are cases where linker and run-time loader need more information >> about ELF objects beyond what the current gABI provides: > > I like the idea. Nick Clifton and I were discussing this at GNU Cauldron 2016. > > I appreciate you have come up with some concrete examples, but I think we > need to take these example and flesh them out completely and see if we have > any problems with your proposed model. Can you pick one of the examples and > flesh out how the bits move from the compiler to assembler to static linker > to dynamic linker and what happens then? > > To kick off that discussion I have questions that range from the compiler > to the dynamic loader: > > (1) How coarse or how fine do you see this checking happening? The current object > you propose, Elf_Prop, is very generic. Could we model more and make life easier > for consumers? The consumers of my proposal are linker and loader. It provided a way to describe program properties to them for the whole object file. > (2) Can you have one ore more pr_type Elf_Prop's in the single object? A sngle object file has one .note.gnu.property.0 note section which is an array of Elf_Prop. If we run out of property types, we can add another property note section. > (3) Can we use Elf_Prop's to mark per-function properties by expressing the function > to be described in pr_data? Perhaps using dwarf? Again, could we model more to > make consumer's simpler to write? Program property covers the whole object file, not individual functions. We can add an auxiliary symbol table for function property. > (4) How do we deal with data-dependent executions that are known to use only > a subset of the shared object features? For example consider code which doesn't use > IFUNCs but instead checks the CPU type, and conditionally executes code, such a > function would be automatically marked as *_NEEDED for all the relevant ISAs, > when it's not true and works today. Do we need to define compiler function attributes > to allow users to change or override the program properties e.g. allow the user > to specify the properties exaclty, disabling automatic generation? AVX is marked as needed only if the program won't run without AVX. In most cases, compiler doesn't know if it is true even when AVX is generated. Only developers know that. > (5) I assume the merging of the notes is dependent on the pr_type and has to have > custom code for that merging? That is correct. > (6) Is there any historical implementations of anything like this? > GNU attribute? But it isn't for run-time loader. -- H.J.