Date: Sat, 18 Nov 2017 22:53:40 +0000 From: Brooks Davis <brooks@freebsd.org> To: Stefan Esser <se@freebsd.org> Cc: Pedro Giffuni <pfg@FreeBSD.org>, Stefan Esser <se@localhost.FreeBSD.org>, src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, rgrimes@freebsd.org, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "O. Hartmann" <ohartman@zedat.fu-berlin.de>, Warner Losh <imp@bsdimp.com> Subject: Re: svn commit: r325954 - in head: . share/mk sys/conf usr.sbin/config Message-ID: <20171118225340.GF35747@spindle.one-eyed-alien.net> In-Reply-To: <0186512e-dc90-6d00-c048-d87a9c1948a3@freebsd.org> References: <201711180134.vAI1Y2ks064138@pdx.rh.CN85.dnsmgr.net> <29499AF9-FC0A-4CDA-9657-B092B3F9A0D0@FreeBSD.org> <04747a89-4dc7-a476-dc32-a158ee1f5240@freebsd.org> <75597b23-7a8c-34ad-736b-8d68ce7dea06@FreeBSD.org> <0186512e-dc90-6d00-c048-d87a9c1948a3@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--mvpLiMfbWzRoNl4x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 18, 2017 at 05:14:28PM +0100, Stefan Esser wrote: > Am 18.11.17 um 16:01 schrieb Pedro Giffuni: > > Hi; > >=20 > > On 11/18/17 09:15, Stefan Esser wrote: > >> Am 18.11.17 um 03:31 schrieb Pedro Giffuni: > >>>> On Nov 17, 2017, at 20:34, Rodney W. Grimes > >>>> <freebsd@pdx.rh.CN85.dnsmgr.net> wrote: > >>>> > >>>> [ Charset UTF-8 unsupported, converting... ] > >>>>> Kib@ posted to arch that we were removing it, nobody objected, we r= emoved > >>>>> it. If it was a working feature that might have a few users, that's= one > >>>>> thing. But I don't think make lint has actually worked in at least = a decade. > >>>> Thats a sad state of affairs. > >>>> > >>> t?s not sad, just the way things are, modern compilers are doing much= of > >>> the checking older tools like lint used to do.. OpenBSD and Dragonfly= BSD > >>> both killed lint ages ago. > >>> > >>> OTOH, we should probably consider other tools, like sparse: > >>> > >>> https://sparse.wiki.kernel.org/index.php/Main_Page > >>> ? The license is fine and it plays nice with the compiler. > >> It builds on -CURRENT, but the Makefile needs some tweaks (it does > >> not find LLVM or Gtk+-2.0, even though they are present on my system). > >> > >> I'll work on a port over the weekend ... > >=20 > > Thanks! >=20 > I've got a port that builds all of sparse except sparse-llvm. The sources > use GNU extensions, and I do not think it is worth the effort to provide > standard compliant replacements for them at this time. >=20 > Building sparc?se-llvm will take some more effort and require the LLVM po= rt > to be installed, since it references headers not installed by our system > compiler. It is an optional component, but one we definitely should have. >=20 > I'm not sure how to proceed, but the easiest path forward is to make the > LLVM support optional and depend on one particular LLVM version (i.e. 4.0 > for now) built from a port if the option is enabled. >=20 > > For it to be really useful we still would have to add annotations to the > > kernel headers. >=20 > Well, those could be added over time ... >=20 > > I just resurrected a recent proposal from brooks@ into the IdeasPage: > >=20 > > https://wiki.freebsd.org/IdeasPage#Userspace_Address_Space_Annotation > >=20 > > It is actually a fun project but my hands are full! >=20 > The port was easy, so far, I'll commit it without sparse-llvm for now. > LLVM support will follow when I've got the remaining build issues resolve= d. I wrote up a port a month or so ago, but I didn't commit it because I belive they authors of sparse failed to understand how C qualifiers work and the __user annotations used in linux are harmful as a result. The problem is that they annotate the data not the pointer. You can make a case for this for the address space annotations, but I believe it's completely wrong for the anti-derefernce guards. I'd hoped that that the linux style __user annotations would be a good match for the __capability annotations we use in CHERI to denote pointers that are capabilities (fat pointers), but they aren't usable. This makes me sad, but I will object to adding these annotations to our tree. (Some of the other annotations look ok, but I've not tested further after this disappointment.) -- Brooks --mvpLiMfbWzRoNl4x Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJaELnzAAoJEKzQXbSebgfApUEH+gOQvsni0/Hv9UbqcmiK1rp2 ZHmu7iFXQknqrnz9z9DeLWvo7tNJYqEU4TyKVbAgJ+lytXVltZ0p/HZWVNpJtwD4 V8a9ueKXicixEDhEu9BDZxr/6muG4HEFX1lfUaxjBhBmcsenQJcZCSvxGxwdjw5x VDnKuf2mlo+SFm7eHUsq/i8xops+mBxmwzbulmYch044Pj/IdcRkMk4srp8D3siT zO+P+9FaxFivGPv+7bIxokVPTT7D1qlxZUz84zmhymeM2xt8uG11tLBssI2/eUGy +TP2fCwy0yNn8Z8o37xWeHw+RGhpfdSMx0w7ROym3tQ7uOcwSEIy7q+VscSkgPQ= =bfAk -----END PGP SIGNATURE----- --mvpLiMfbWzRoNl4x--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171118225340.GF35747>