From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126289 invoked by alias); 18 Feb 2020 21:43:42 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 126280 invoked by uid 89); 18 Feb 2020 21:43:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-ot1-f52.google.com Received: from mail-ot1-f52.google.com (HELO mail-ot1-f52.google.com) (209.85.210.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Feb 2020 21:43:39 +0000 Received: by mail-ot1-f52.google.com with SMTP id w23so4647299otj.4 for ; Tue, 18 Feb 2020 13:43:39 -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=ST2hCQ9QtBIxUIEMTN9QkuKlVIx7o2sVlC1eNsg1lTk=; b=lEDR+5Vz9ymXyJoYGvBfx2IkjLloCHFY4bWqkuS6CNr6JFttHr0A8vRDQCDfFX+7qv t5+AtD0W674m6pFvXx9A+bUpWyAnIOzutmvk0+V2pBRqWIPWj6iPPdr6kjrdUB3pGIGD u0kMLCuCLvhlYmv37NkGMPNSbdykzUjfXURpmtpepjwFT+xcrGQrMa3fwO9xRJg2Sor2 vOOkJvNOfdGMZY5BovO8oJo1me490h3wYGOrK43papozny0bAFR+Jl+hZMCy9oNRvzWH SviBV2HUAEZUcb5QpFaPrs3bUoa1M/Pz6KrnEjs19hrCMLvZ296Kn6ol4iNSHj4XCQMy QM/w== MIME-Version: 1.0 References: <20200218102515.54ab5fff@jozef-kubuntu> <20200218134747.00b0c400@jozef-kubuntu> <20200218143857.5dc40e08@jozef-kubuntu> <20200218185454.056abc91@jozef-kubuntu> In-Reply-To: <20200218185454.056abc91@jozef-kubuntu> From: "H.J. Lu" Date: Tue, 18 Feb 2020 21:43:00 -0000 Message-ID: Subject: Re: [RFC] Symbol meta-information ELF extension To: Jozef Lawrynowicz Cc: "binutils@sourceware.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00430.txt.bz2 On Tue, Feb 18, 2020 at 10:54 AM Jozef Lawrynowicz wrote: > > On Tue, 18 Feb 2020 06:50:58 -0800 > "H.J. Lu" wrote: > > > On Tue, Feb 18, 2020 at 6:38 AM Jozef Lawrynowicz > > wrote: > > > > > > On Tue, 18 Feb 2020 05:58:34 -0800 > > > "H.J. Lu" wrote: > > > > > > > On Tue, Feb 18, 2020 at 5:47 AM Jozef Lawrynowicz > > > > wrote: > > > > > > > > > > On Tue, 18 Feb 2020 04:58:02 -0800 > > > > > "H.J. Lu" wrote: > > > > > > > > > > > On Tue, Feb 18, 2020 at 2:26 AM Jozef Lawrynowicz > > > > > > wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I've been working with Texas Instruments to develop an ELF extension which > > > > > > > allows additional information about symbols ("symbol meta-information") to > > > > > > > be stored in ELF files, in a section called .symtab_meta. > > > > > > > > > > > > > > The aim of symbol meta-information is to provide a extensible format for > > > > > > > propagating additional information about symbols from the source code through to > > > > > > > the link stage. > > > > > > > > > > > > > > I hope I can get some feedback on this proposal, and its current implementation, > > > > > > > from the upstream community so I can make any adjustments required for the > > > > > > > eventual upstreaming of this feature. > > > > > > > > > > > > Have you looked at Solaris syminfo section > > > > > > > > > > > > https://docs.oracle.com/cd/E26502_01/html/E26507/chapter7-17.html > > > > > > > > > > > > Can you extend it to do what you want? > > > > > > > > > > > > > > > > It looks like there is only some minimal support for the Syminfo section in > > > > > Binutils. The support is only there so that readelf can dump information about > > > > > the Syminfo section from an object file. > > > > > > > > > > There's no implementation to enable the creation of a Syminfo section with > > > > > user-specified flags for certain symbols, nor are there any hooks into any > > > > > other Binutils programs, so I can't see any advantage to try and leverage that > > > > > existing functionality. > > > > > > > > syminfo is a very useful ELF extension. My question is if binutils supports > > > > syminfo, can it be extended to meet your need? > > > > > > > > > > > > > > Well, a syminfo entry has a field to store flags which describes the extra > > > information about the symbol, similar to the "kind" field of a symbol > > > meta-information entry. > > > > > > typedef struct { > > > Elf64_Half si_boundto; > > > Elf64_Half si_flags; > > > } Elf64_Syminfo; > > > > > > Meanwhile, syminfo augments the si_flags value by using si_boundto to point > > > to an index in the .dynamic section. This is similar to how the "value" field of > > > a symbol meta-information entry augments its "kind" field, but this > > > functionality must work in static executables which do not have a .dynamic > > > section. > > > > > > So one way to extend syminfo to meet the general need of this proposed symbol > > > meta-information functionality then we would need a new field to store the > > > value associated with the "si_flags". > > > > > > typedef struct { > > > Elf64_Half si_boundto; > > > Elf64_Half si_flags; > > > Elf64_Addr si_value; > > > } Elf64_Syminfo_new; > > > > You should start a discussion to extend ELF symbol info at > > > > https://groups.google.com/forum/#!forum/generic-abi > > Thanks for the suggestion. I'll work with TI to get something posted there soon. > > Can you clarify whether you still think this would work best as an extension to > Solaris Syminfo? > > To be honest I have a problem with that given that Syminfo is a target specific > extension to ELF (which just happens to be implemented in a generic way in > Readelf), and we want to add symbol meta-information as a generic extension > to ELF. > > There's no advantage to building upon Syminfo in Binutils given the > implementation is limited to readelf dumping the Syminfo table. > > If Syminfo was already part of the gABI I would be on board with working from > that to add the new functionality. > > I guess the other option is to take Syminfo, extend it with the new > functionality we want, then propose it as generic ELF extension. I wonder if > there would be legal issues doing all that without any input from Oracle. > > Do they "own" the spec? Would I be able to propose their spec with some > extensions to ELF gABI? (These are somewhat rhetorical questions...) https://groups.google.com/forum/#!forum/generic-abi is the place to discuss ELF gABI. -- H.J.