From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) by sourceware.org (Postfix) with ESMTPS id 478DE3857C48 for ; Wed, 2 Sep 2020 10:26:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 478DE3857C48 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=mittosystems.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jozef.l@mittosystems.com Received: by mail-wm1-x32c.google.com with SMTP id e11so2850427wme.0 for ; Wed, 02 Sep 2020 03:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mittosystems.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=HNRgRMqka1CIiFN2S8u7vdb0felBvLiLdRhizmenqUw=; b=N362Bge/KTXFL1mC+ZHVzwSmNv9jOej2+43LJyXe/E4+Jn3U5RGXrZ5KbyGu2PWnl0 XryuFdUOnqjh3ywllZyaxiOjOazmhUw9choiR/iEeIdiF/Fg4O54t3cx1rLFRLKYglLn rF52MsUU05G6jrVQgpfJkCvFoQffidBvBwJBm5HFzI+8toVtCLO8jQfvHYfL5icwlpFi vmpM/ERBGcZkYvmi9PYR0g0rZoNMqIh4ZvwvY7EdIxLwu7pVX0IcO+wAMQu6xcL/3fEc IxIaQrZ0EPgaQQjOLNU+yqbof5pFC4ABL9CASXeFp3Nb7ecUqwC2HdYQEqrYmWbwywB3 EEQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=HNRgRMqka1CIiFN2S8u7vdb0felBvLiLdRhizmenqUw=; b=ABMyIbFD18TVOzupDPwPkp5j2ZkU94oWtiKKludGT7pvNrTVIFeixnuu9MkofrfrYe Cb1arbfK/aTJlzkkomosfbLamYT7YGCr4cmnERGmctUW2+1fAqJ4Z70X7lDvEKN9HMST A9lqYNguwxKw9Y0MqgE1C0VpLEiJBkVeLkZvvoL6vODwHoRl4SH9h0AxdqvJzPrXVNdu 0fhSzkPDwmTopXbLIh2uDmP7q3l43r430Y602FI9ApJARMP0ZyAlzSphXU60hIYV+cJo 4hSuBYDP7uDgQRT5YR/FP055z1gqPUYH+qTTd8w4Cm2tHV1oZwvRUQ4Gm7/ASPB/HDtP TAUw== X-Gm-Message-State: AOAM531kYN5iqktnvK5tZmOlVm0t3oQE/mX4+5te7snNFBmLB2Auz3vu hKt1ShBFvQe2uA9XbwOAkBzYPcBDfCcd0g== X-Google-Smtp-Source: ABdhPJw2E3bAFnOm4ALgQ+sbmYA7bBpZFeAlvK+VmyqRWrxGDt2hsMziiZpzEf8DOE0mKPONs1HKSg== X-Received: by 2002:a1c:234b:: with SMTP id j72mr6247283wmj.153.1599042385309; Wed, 02 Sep 2020 03:26:25 -0700 (PDT) Received: from jozef-acer-manjaro ([2a01:4b00:87fd:900:5e1d:5c99:56da:76e8]) by smtp.gmail.com with ESMTPSA id q12sm6133090wrs.48.2020.09.02.03.26.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Sep 2020 03:26:24 -0700 (PDT) Date: Wed, 2 Sep 2020 11:26:23 +0100 From: Jozef Lawrynowicz To: Florian Weimer Cc: James Y Knight via Gnu-gabi Subject: Re: [RFC] Proposal for new ELF extension - "Symbol meta-information" Message-ID: <20200902102623.w7gj7zxhkitonzfi@jozef-acer-manjaro> References: <20200831115859.mwcruabbzoj3x4w7@jozef-acer-manjaro> <875z8zj95u.fsf@oldenburg2.str.redhat.com> <87sgc1u4jz.fsf@oldenburg2.str.redhat.com> <20200901121922.srcmdfc4o4rd62go@jozef-acer-manjaro> <873641u0hn.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <873641u0hn.fsf@oldenburg2.str.redhat.com> X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gnu-gabi@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnu-gabi mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 10:26:45 -0000 On Tue, Sep 01, 2020 at 02:48:04PM +0200, Florian Weimer wrote: > * Jozef Lawrynowicz: > > > I can imagine how the behavior could be implemented without any special > > handling from the linker, if the compiler instead maps the printf calls to the > > minimum required printf implementation, and the library has something > > like this: > > Yes, exactly my thought. It's definitely less action at a distance. > > > Do you have any opinions on the inclusion of the symbol meta-information > > mechanism itself within the GNU gABI? > > In the past, we just added a parallel table to the symbol table when we > needed to extend it. I think SHT_GNU_versym is the most widely used > example. This has the advantage that it is so much simpler. It seems that the benefits of having a parallel symbol table outweigh any concerns about wasted space and the large amount of symbol metainfo entries which would not have any content. Since entry size is fixed, if you stored the header information in the initial NULL entry then there is the additional benefit that you could theoretically keep .symtab_meta in sync with .symtab by adding/removing symbols at a given index as required. > > The main risk is processing objects with tools that don't know about the > symbol table relationship of this parallel tables. To deal with that, > having a special section that lists the section types that absolutely > need to be understood by tools in order to process the object in various > ways (a distinction between reading, linking, and outputting might make > sense) could really be helpful. You would get a precise error, rather > than a corrupt output file. > > I'm not sure if it is possible to have meaningful symbol metadata that > can be processed by old tools in some meaningful way, tools that have no > prior knowledge of it. It's very hard to design these things, > especially when we have only three established use cases. Some standardization of parallel symbol tables would certainly be forward thinking and enable future extensions which use parallel symbol tables to be kept in sync with .symtab, even if those older tools don't understand the extension itself. If we also consider SMT_NOINIT removed as a generic metainfo type, based on the feedback received from the ELF gABI discussions, then that leaves the SMT_RETAIN and SMT_LOCATION metainfo types. These types in particular generally operate on the section level, at least, the behavior the linker will eventually apply will be to the containing section, not the symbol itself. So they could be implemented using new section flags (sh_flags). There is plenty of space for additional sh_flags (unlike symbol flags). - SMT_RETAIN The linker will only garbage collect sections, not individual symbols. A new section flag indicates that the section should be retained by the linker, even if it would be garbage collected. Whatever section contains the symbol that the "retain" attribute is applied to will have the "retain" sh_flags bit set. - SMT_LOCATION The linker can only place sections at a specific address, not individual symbols. A new section flag indicates that the section should be placed at a specific VMA in the executable file by the linker. The address could be set in the sh_addr field, or encoded in the section name. Since the overall aim is to support the "retain" and "location" C/C++ attributes, perhaps this is the most appropriate way forward... Thanks, Jozef