Date: Sat, 18 Nov 2017 19:37:57 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Brooks Davis <brooks@freebsd.org>, Stefan Esser <se@freebsd.org> Cc: 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: <1db2e302-192c-0c9c-5987-6a2eb117d2a8@FreeBSD.org> In-Reply-To: <20171118225340.GF35747@spindle.one-eyed-alien.net> 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> <20171118225340.GF35747@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/18/17 17:53, Brooks Davis wrote: > On Sat, Nov 18, 2017 at 05:14:28PM +0100, Stefan Esser wrote: >> Am 18.11.17 um 16:01 schrieb Pedro Giffuni: >>> Hi; >>> >>> 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 removed >>>>>>> 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 DragonflyBSD >>>>> 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 ... >>> Thanks! >> 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. >> >> Building sparc?se-llvm will take some more effort and require the LLVM port >> to be installed, since it references headers not installed by our system >> compiler. It is an optional component, but one we definitely should have. >> >> 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. >> >>> For it to be really useful we still would have to add annotations to the >>> kernel headers. >> Well, those could be added over time ... >> >>> I just resurrected a recent proposal from brooks@ into the IdeasPage: >>> >>> https://wiki.freebsd.org/IdeasPage#Userspace_Address_Space_Annotation >>> >>> It is actually a fun project but my hands are full! >> 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 resolved. > 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. Hmm ... I was expecting we could use it for a check-mode build but never for ship anything resulting from it. Now it seems like something that we should not fiddle with but instead leave to the llvm developers to implement. > 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.) OK, so it's better to know that. The ports tree has devel/splint. Disclaimer: I have never played with isplint and it's copyleft, but I doubt we want to bring another lint-like utility to the tree, so perhaps the license doesn't matter in this case. Pedro. > -- Brooks
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1db2e302-192c-0c9c-5987-6a2eb117d2a8>