Date: Thu, 14 Aug 2014 09:55:04 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: Phil Shafer <phil@juniper.net> Cc: arch@freebsd.org, Poul-Henning Kamp <phk@phk.freebsd.dk>, Marcel Moolenaar <marcel@freebsd.org>, John-Mark Gurney <jmg@funkthat.com>, "Simon J. Gerraty" <sjg@juniper.net> Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML Message-ID: <39394555-F1DE-4D8E-9161-AD179EB3B8FC@xcllnt.net> In-Reply-To: <201408140452.s7E4qB2X091511@idle.juniper.net> References: <201408140452.s7E4qB2X091511@idle.juniper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_90C93917-7538-4938-B778-D1BD0878691D Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Aug 13, 2014, at 9:52 PM, Phil Shafer <phil@juniper.net> wrote: > >> The question is: do we have >> more features we want to check for this way? If not, then >> such a scheme could be perceived as "heavy handed". > > "heavy handed" in what sense? A generic implementation calls for a utility that can list features, check for a feature, add and remove features. You probably want to have support libraries as well to do the same thing from within C and C++, etc. If all we're talking about is libxo then there are surely less work-intensives ways to achive what we want. In that sense heavy-handed. > I'm hoping the note can be added by normal linker magic (but see > question below). If not a "noteelf" command would need to be created > (or an option to brandelf?) to mark the binary. Ideally, features set in the same way we do for. the kernel. Only in the kernel it ends up being a sysctl, which doesn't apply here. Alternatives in the kernel are linker sets and I've used those in mkimg as well. A linker set is like a note, except that the metadata is in a loadable section and thus part of a loaded segment. This has the advantage of being able to go over your own set of features from within C and C++, etc and it doesn't require a utility to add and remove features to a set. Checking for a feature from some other program is probably as hard as a note, assuming there was a single note to list all features. In both cases you first have to find the container with some ELF grokking utility and then you need to parse the container's data to find a feature. A note has the benefit over a section in that I can make changes without having (effectively) to relink. > Are you seeing > something more? "elfdump" has a "-n" to dump notes, and a "-N > <name>" could be added, making "elfdump -n -N libxo my-app" the > means of getting the contents. A "-q" option could be added to > prevent output but set the exit code based on if the section appears > in the given binary. I think I prefer a more intergated solution in the end. elfdump is that "ELF grokking" utility, but may not necessarily be appropriate for the interpretation of the feature set. But that's for later. For now, something that works as a prototype is good enough. > >> Alternatives include looking for a particular symbol or >> possibly even running the utility with a libxo option that >> has predictable output. > > How does one put a symbol in a binary when linking against a shared > library? One doesn't necessarily. A recursive search that follows the DT_NEEDED could possibly work well enough. Though, I fear for the likes of Mozilla that large number of shared libraries. Not that such is our immediate scope/target, but if there is an approach that scales well, then that would be better. > Would there need to be two libs, one with the code and > one with just a symbol? I'd have the same issue with the ElfNote > scheme, right? I'd need to add a section to the binary, but libxo > could be linked dynamically. Is there an easy answer for this? Or > is the app stuck with "LDADD+=-lxo -lxo-note"? I don't have a good answer other than that there isn't a suitable option to LD to leave a turd in the executable. The absolute easiest is to simply not support static linking for libxo and then simply check DT_NEEDED. You can use ldd for that. That route wouldn't require anything other than not (ever) building an archive library for libxo. This is not unreasonable either. The world has moved away from archive linking for the most part and while there's still value to static linking, I see it needed less and less. -- Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_90C93917-7538-4938-B778-D1BD0878691D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlPs6egACgkQpgWlLWHuifbmsACdEl1/+hyNwUkBG+DfL2r2iOHi 840AnAzX8854JbJ89y53tifxXsaZwQYZ =0Ysq -----END PGP SIGNATURE----- --Apple-Mail=_90C93917-7538-4938-B778-D1BD0878691D--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39394555-F1DE-4D8E-9161-AD179EB3B8FC>