From owner-freebsd-arch@FreeBSD.ORG Thu Aug 14 14:08:53 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1321AE8F; Thu, 14 Aug 2014 14:08:53 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C65432A9A; Thu, 14 Aug 2014 14:08:52 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XHvhx-000KVa-6r; Thu, 14 Aug 2014 14:08:49 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s7EE8lhZ037675; Thu, 14 Aug 2014 08:08:47 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+/Mpyv0Pz48DNgNaJdfRV/ X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20140814085257.GN2737@kib.kiev.ua> References: <20140814052648.GM2737@kib.kiev.ua> <201408140606.s7E66XXA091972@idle.juniper.net> <20140814085257.GN2737@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Aug 2014 08:08:46 -0600 Message-ID: <1408025326.56408.566.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: marcel@freebsd.org, Phil Shafer , John-Mark Gurney , "Simon J. Gerraty" , arch@freebsd.org, Poul-Henning Kamp X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 14:08:53 -0000 On Thu, 2014-08-14 at 11:52 +0300, Konstantin Belousov wrote: > On Thu, Aug 14, 2014 at 02:06:33AM -0400, Phil Shafer wrote: > > Konstantin Belousov writes: > > >Yes, the notes are used to communicate the information required by > > >the dynamic linker to correctly activate the image. The mechanism has > > >nothing to do with application-specific features, and overloading it for > > >that purpose is severe and pointless layering violation. > > > > The ELF spec says: > > > > Note Section > > > > Sometimes a vendor or system builder needs to mark an object > > file with special information that other programs will check > > for conformance, compatibility, etc. Sections of type SHT_NOTE > > and program header elements of type PT_NOTE can be used for > > this purpose. The note information in sections and program > > header elements holds any number of entries, each of which is > > an array of 4-byte words in the format of the target processor. > > Labels appear below to help explain note information organization, > > but they are not part of the specification. > ELF standard scope is about build toolchain and C runtime, where the > cited paragraph makes perfect sense. > I disagree with this interpretation. The cited paragraph can be found in, for example, the Oracle documentation in a chapter named "object file format". There is nothing about the context that limits the validity to toolchains and runtime support, it's just describing the file layout. It appears to me that the NOTE mechanism is purposely designed for attaching arbitrary metadata of any size and type to an elf file. A bit of searching doesn't turn up any words that either recommend or forbid certain types of info stored in NOTEs. > > > > Marking the binary with a libxo-specific note tells the caller that > > the binary is capable of rendering its output in a non-traditional > > style and gives the caller a means of triggering those styles of > > output. In the libxo-enabled world, I see this as vital information > > the caller needs to initialize the environment in which the command > > will be run. Isn't this exactly the sort of information ELF targets > > for note sections? > > How binary format has any relevance for an application level feature ? > What would you do with the binaries which permissions are 'r-s--x--x', > which is not unexpected for the tools which gather system information > and have to access things like /dev/mem ? > > You removed and did not answered a crusial question, which is a litmus > test for your proposal. Namely, how presence of the proposed note in > the binary is different from DT_NEEDED tag for your library ? DT_NEEDED only helps with dynamically linked executables, this whole NOTEs discussion came up in the context of how to detect a statically linked binary with libxo output support. > > Definitely, I do not see an addition of the fashion-of-the-day > text-mangling output shattering enough to justify imposing the > architecture violation. I don't think you've cited anything other than your own opinion that using a note is any sort of architecture violation. I don't know that you're wrong, I just can't find anything with a bit of quick searching that says you're right. -- Ian