From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76628 invoked by alias); 14 Oct 2016 02:24:41 -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 76592 invoked by uid 89); 14 Oct 2016 02:24:36 -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.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=Hx-languages-length:1926, coarse, ore, H*r:sk:gnu-gab X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM 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-qt0-f181.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:organization:cc :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=rX/hAhiF/l+1NBFZ7yuJyDyKErAh/grXk50CkWRL3Cw=; b=LsPLwAiRwEGf7ZH0cr4KxrXGoe84gH99L7bT66cED3Am2mIEB0m5X2J2DcaxmWIN5F 0ujCEBTLZiamINgHkMElzgXAht8cano6lasRz2YnEMi4KRN9ce8iD0UPy9IERrpvJf6W 92XFAR4HTmDbL85uX/TM6b/Zetifpr6bSgGWfAkAYCJmZ/6dJrreCGLfT58s1sgnmb01 fCHCZdYTn1Kv304rLO3tbFyO4O2HzDGAVny/oIyNCKsni/x2wUy/135zMEJDy0ejSdmE kWhfCV/loBxJcgvJzYsqhx3Z6FIlCE3o4jBv124+ru8IGB4HXwhb5+WxAnE3yxXJ5Vyj HREA== X-Gm-Message-State: AA6/9RmKQwJzWM6ShToSGuclfVgbT2xWhEPJkmDr2YtUlYhs7Ot890/JeUSZ5VGqRnpT7Il0 X-Received: by 10.200.52.28 with SMTP id u28mr10216311qtb.87.1476411873412; Thu, 13 Oct 2016 19:24:33 -0700 (PDT) Subject: Re: RFC: Program Properties To: "H.J. Lu" , gnu-gabi@sourceware.org References: From: Carlos O'Donell Organization: Red Hat Cc: Nick Clifton Message-ID: <969fb6da-f13c-eb14-3e53-94a594384518@redhat.com> Date: Fri, 01 Jan 2016 00:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-q4/txt/msg00005.txt.bz2 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? (2) Can you have one ore more pr_type Elf_Prop's in the single object? (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? (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? (5) I assume the merging of the notes is dependent on the pr_type and has to have custom code for that merging? (6) Is there any historical implementations of anything like this? -- Cheers, Carlos.