From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 0B581384241D for ; Tue, 1 Sep 2020 12:48:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0B581384241D Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-461-m80-_i9xP2C5NIm5D-abww-1; Tue, 01 Sep 2020 08:48:08 -0400 X-MC-Unique: m80-_i9xP2C5NIm5D-abww-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1A890801A9E; Tue, 1 Sep 2020 12:48:07 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-113-228.ams2.redhat.com [10.36.113.228]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 539247C564; Tue, 1 Sep 2020 12:48:06 +0000 (UTC) From: Florian Weimer To: Jozef Lawrynowicz Cc: James Y Knight via Gnu-gabi Subject: Re: [RFC] Proposal for new ELF extension - "Symbol meta-information" References: <20200831115859.mwcruabbzoj3x4w7@jozef-acer-manjaro> <875z8zj95u.fsf@oldenburg2.str.redhat.com> <87sgc1u4jz.fsf@oldenburg2.str.redhat.com> <20200901121922.srcmdfc4o4rd62go@jozef-acer-manjaro> Date: Tue, 01 Sep 2020 14:48:04 +0200 In-Reply-To: <20200901121922.srcmdfc4o4rd62go@jozef-acer-manjaro> (Jozef Lawrynowicz's message of "Tue, 1 Sep 2020 13:19:22 +0100") Message-ID: <873641u0hn.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0.002 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, 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: Tue, 01 Sep 2020 12:48:13 -0000 * 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. 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. Thanks, Florian