From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8844 invoked by alias); 17 Oct 2016 15:55:46 -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 8818 invoked by uid 89); 17 Oct 2016 15:55:45 -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=H*r:sk:gnu-gab, wish 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-f182.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=fi/8X0FKoz8vmbwtLdfpsNTXWqOeI2fvADm2z11NPbc=; b=audpmkUtFbgsdIFeqondsuHVliRwijbV4bQhYdqtOYDao+DeeqipF6WgIH7lQIORAT Q9oeCNov6ONvQOCfVqOPp1p5cBLohe/9X6gLDHM93o5ECyd2Ah1KeJoOp1HuWm6XErmh F5j2qo9C9c3+bvsgAzL59Ih1Lpb97vSYCvVIuZCQaM4iGdKsr0+dFivjuGYxLe/lvB0k GiecZBeCkK/7y8ZJbCe0aNty0yo2Bhl51w6ttxAXPCOwo9ZjpTlmr5GJ1++7jkgOkEp3 pme7EZaF1DfN7lvJPApD1eDa92mg58beF01OPGoTm8Qu39nlM8dCt9AP5lcdJKejo5Zu ibHw== 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=fi/8X0FKoz8vmbwtLdfpsNTXWqOeI2fvADm2z11NPbc=; b=iFGfweQz3/f8xO46rPyj9libAyWrp18JtPyP61dtDe4CbHbMEWpDPuKcS3htC8pq3L P/PC0h56Yfkh2IrW81xyGARxx6KMv3XC0cHprEOadk4kNPoBvXC+Ka6ZyoGt5+zEeQSd nv+hIXjAd9+gAm4bt7yPpOQS1vyp/ZChlZpJMaTdfGnY6/LD3+vEUOlRspyFwIq8gOyJ 08+kmbMAuaEtKbVIcPi4uZ3N+VWyP4nlIW6yefB7bdVhAkQrBGG3/3OiVwPUvO09iI8t F85DW76URm9eXWYNT/FKyGcnRfyo46wSMt4DRhLr3P0/zARJMSOwwlOAbirUBUaZPmhN eBOA== X-Gm-Message-State: AA6/9RmGZ59Tk5lrGjbDCRHOYdd94F1PvbjknHQTAJoyzmlTfvlEz3RXKpEQdiq8Pk+efkL+JVU6XgaNEYFlJQ== X-Received: by 10.55.106.2 with SMTP id f2mr22572124qkc.124.1476719733457; Mon, 17 Oct 2016 08:55:33 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: 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: "Maciej W. Rozycki" Cc: "Carlos O'Donell" , gnu-gabi@sourceware.org, Nick Clifton Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-q4/txt/msg00010.txt.bz2 On Mon, Oct 17, 2016 at 6:32 AM, Maciej W. Rozycki wrote: > On Thu, 13 Oct 2016, Carlos O'Donell 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 wish I was there. :( > >> (6) Is there any historical implementations of anything like this? > > The MIPS target has been using a mixture of ELF file header's `e_flags' > member flags (EF_MIPS_*) which we have now run out of, GNU attributes > (Tag_GNU_MIPS_ABI_*, Val_GNU_MIPS_ABI_*) interpreted by the static linker > only, and more recently a processor-specific "MIPS ABI Flags" section > (SHT_MIPS_ABIFLAGS) and segment (PT_MIPS_ABIFLAGS). Some of this > information although not necessarily all at once is interpreted by the > static linker, the Linux kernel (e.g. to verify the compatibility of a > binary against hardware and the dynamic loader), and finally the dynamic > loader. > > I think it would make sense if the design of program properties let us > wire the existing target-specific data structures if possible, so that > e.g. a MIPS ABI Flags section/segment could be interpreted as a part of > the new data structures. > > Also based on the experience with MIPS ABI Flags so far I would suggest > defining generic ABI flag flags so that individual object file's ABI flags > can be handled in a generic way in linking; the flags I'd initially > propose would be: > > 1. An OR flag: if such annotated the ABI flag produced in output is a > logical OR of the values of the ABI flag in input objects. Reasonable. > 2. An AND flag: if such annotated the ABI flag produced in output is a > logical AND of the values of the ABI flag in input objects. Reasonable. > 3. An equality flag: if such annotated linking fails if the values of the > ABI flag in input objects are not the same across all of them. Reasonable. > 4. A reject flag: if such annotated the ABI flag requires explicit support > (special handling beyond the three variants above) and linking fails if > it is set in any input object and the linker does know this ABI flag. "reject" isn't very clear. Is "mandatory" better? > Such annotation would of course have to be consistent across input files. > > Such ABI flag flags would allow ABIs to define new ABI flags processed > automatically in static linking without the need to upgrade the linker > each time a flag is added. > > Thoughts? Property values can be divided into ranges of different rules, including rules which differ from above. -- H.J.