Re: System headers with clang?
Hi, On Tue, Oct 11, 2011 at 9:09 PM, Julian Elischer wrote: > On 10/11/11 12:57 PM, Arnaud Lacombe wrote: >> >> Hi, >> >> On Tue, Oct 11, 2011 at 3:42 PM, Julian Elischer >> wrote: >>> >>> On 10/11/11 12:36 PM, Arnaud Lacombe wrote: > > [...] >> I will repeat myself here, but I ran what-was-to-become-Linux-v3.2 >> kernel on a 4 years old openwrt image and still had a functional >> system. Comparatively, I could not mix FreeBSD 7-STABLE userland and >> 8-STABLE kernel, The 8-STABLE kernel even changed the FS enough to >> make FreeBSD 7 unable to boot (even single user). > > actually due to libkvm there are actually a lot of programs that will work > over the > 7-8 boundary... a lot more than used to. between, say 2 and 3. > >> Let me emphasize again that it is only my personal opinion :-) > > Yep but its shared.. Unfortunately the problem is actually trickier than > first appears. > My own attempt at it can be seen with netgraph, where we instituted a text > based > config scheme, and in geom where PHK made an XML config scheme. > it would seem that any attempt to solves that problem somehow ends-up to hierarchically text-encode/decode the binary data, Linux /proc / /sys text file-based interface, the netgraph encoding (which I admit is really powerful once dominated), phk's XML config scheme, NetBSD & Apple property list :) - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
On 10/11/11 12:57 PM, Arnaud Lacombe wrote: Hi, On Tue, Oct 11, 2011 at 3:42 PM, Julian Elischer wrote: On 10/11/11 12:36 PM, Arnaud Lacombe wrote: [...] libprocstat is _itself_ a problem: % git grep 'define _KERNEL' . [...] lib/libprocstat/cd9660.c:#define _KERNEL lib/libprocstat/nwfs.c:#define _KERNEL lib/libprocstat/smbfs.c:#define _KERNEL lib/libprocstat/udf.c:#define _KERNEL lib/libprocstat/zfs.c:#define _KERNEL [...] ok, I admit this is all FS related stuff :) but at least it comes with the system so it matches. no, you should be able to run a FreeBSD 1.0 userland and a 9-RELEASE kernel together and have all utilities working. If not, you cannot claim to support backward compatibility, even if you do on a subset of kernel/userland interface. That said, this is just my personal opinion. we've been looking for the 'right' way to do this since, hmmm, 1988 that I remember and I bet before that too. then the job was done bad. I didn't say we DID it I said we've been looking for the right answer. libkvm was a small step... you really don't want to know what was done before that. I've run FreeBSD 1.1 on a freeBSD 8 jail so I know what you mean, you have to put some things like 'ps' and ifconfig, and 'netstat' into it (statically compiled) or you can't get anywhere but even if there was a differnt interface, the likelyhood of it still being valid after 19 years pretty small. I will repeat myself here, but I ran what-was-to-become-Linux-v3.2 kernel on a 4 years old openwrt image and still had a functional system. Comparatively, I could not mix FreeBSD 7-STABLE userland and 8-STABLE kernel, The 8-STABLE kernel even changed the FS enough to make FreeBSD 7 unable to boot (even single user). actually due to libkvm there are actually a lot of programs that will work over the 7-8 boundary... a lot more than used to. between, say 2 and 3. Let me emphasize again that it is only my personal opinion :-) Yep but its shared.. Unfortunately the problem is actually trickier than first appears. My own attempt at it can be seen with netgraph, where we instituted a text based config scheme, and in geom where PHK made an XML config scheme. - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
Am 11.10.2011 15:31, schrieb Larry Rosenman:
> On Tue, 11 Oct 2011, Dimitry Andric wrote:
>
>> On 2011-10-09 19:32, Larry Rosenman wrote:
>>> I had gotten a PR about sysutils/lsof not compiling with clang. I had
>>> Vic Abell check it out, and the problem is NOT with lsof per se, but
>>> with the system headers.
>>>
>>> Is there a project afoot to update the system headers to make them clang
>>> compilable?
>>
>> The problem isn't that clang can't compile the system headers, but
>> normally these don't get included from userspace. And they certainly
>> won't work as expected when you define _KERNEL in userspace, as the lsof
>> port foolishly does. It probably can't be avoided in such a tool,
>> though.
Point #1: some of the headers have special requirements, like inclusion
order, or thereabouts. Since these are kernel headers, you need to
abide by their rules.
Violated here:
>>
>>
>> ...
>>> In file included from ckkv.c:43:
>>> In file included from ./../lsof.h:195:
>>> In file included from ./../dlsof.h:190:
>>> In file included from /usr/src/sys/ufs/ufs/ufsmount.h:36:
>>> /usr/src/sys/sys/buf.h:388:2: warning: implicit declaration of
>>> function 'KASSERT' is invalid in C99
>>> [-Wimplicit-function-declaration]
>>> KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p",
>>> bp));
>>> ^
I *suppose* KASSERT is meant as a macro, but even if it's not, ...
>>> /usr/src/sys/sys/buf.h:388:33: warning: expression result unused
>>> [-Wunused-value]
>>> KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p",
>>> bp));
>>> ^
>>
>> These are more or less harmless warnings, as long as nobody calls a
>> function that uses KASSERT. They occur because lsof's headers don't
>> include and before .
...I'd say that's an lsof, rather than kernel or clang, bug.
>>
>> ...
>>> In file included from ckkv.c:43:
>>> In file included from ./../lsof.h:195:
>>> In file included from ./../dlsof.h:432:
>>> In file included from /usr/include/string.h:45:
>>> /usr/include/strings.h:47:6: error: conflicting types for
>>> '__builtin_ffs'
>>> int ffs(int) __pure2;
>>>^
>>> /usr/include/machine/cpufunc.h:140:24: note: expanded from:
>>> #defineffs(x) __builtin_ffs(x)
>>> ^
>>> /usr/include/strings.h:47:6: note: '__builtin_ffs' is a builtin with
>>> type 'int (unsigned int)'
>>
>> This is because the amd64 system headers redefine ffs to __builtin_ffs,
>> after which it conflicts with the declaration in /usr/include/strings.h.
>> On i386, ffs is not redefined, but I have no idea why.
Arguably __builtin_ffs() is inconsistently defined if it expects an
unsigned int argument. POSIX demands int for ffs()'s argument.
The builtin should match that. I can't currently point fingers at the
culprit for lack of research/information.
Chances are -fno-builtin helps.
> We need to get clang/system headers to allow warning free compilation
> just like GCC does.
Then make sure that your code is correct. NOTE: GCC defaults to C89
with GNU extensions, clang defaults to C99. To know how GCC treats your
code in C99 mode, try gcc -pedantic-error -std=c99 (or possibly
-pedantic without -error suffix if there are bogus warnings) and see if
it's really clang -- or rather the code...
You can override options for either in the port, see
http://wiki.freebsd.org/PortsAndClang#Problems_with_fixes and look for
USE_CSTD.
It won't make your (Vic's) code future proof, but may help for the nonce
- or not.
Of course Vic is free in writing arbitrarily nonportable code, but
before he or you go(es) pointing fingers, check if you're using kernel
headers properly and requesting compilation in the right language, and
if the code is actually conformant.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
Hi, On Tue, Oct 11, 2011 at 3:24 PM, Garrett Cooper wrote: > On Tue, Oct 11, 2011 at 11:36 AM, Arnaud Lacombe wrote: >> Hi, >> >> On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andric wrote: >>> On 2011-10-09 19:32, Larry Rosenman wrote: I had gotten a PR about sysutils/lsof not compiling with clang. I had Vic Abell check it out, and the problem is NOT with lsof per se, but with the system headers. Is there a project afoot to update the system headers to make them clang compilable? >>> >>> The problem isn't that clang can't compile the system headers, but >>> normally these don't get included from userspace. And they certainly >>> won't work as expected when you define _KERNEL in userspace, as the lsof >>> port foolishly does. It probably can't be avoided in such a tool, though. >>> >> #ifdef _KERNEL/#endif protected part of system headers shall NEVER be >> accessed by userland. It is a fault to have them present in >> /usr/include. Linux got it right there, all those part are removed >> upon headers' installation. > > Yes, but instead Linux encourages mucking around with /proc and /sys, > which have varying levels of formatting and provided output. > At least, interfaces exist (/proc and /sys) and the data are formatted enough (ASCII text) to abstract the underlying binary format. > The data needs to be exported properly via sysctl. If it's not done > that way to userland, then the API/KPI is flawed and needs to be > revised. > just exporting raw data would not do the job; it can already be done with KVM. What is needed is a defined ABI (ie. interface, data and format) between the kernel and userland. I'm not even considering it being stable for now, this would be the subject of another thread. NetBSD has done the interesting move of using property list for kernel/userland structure encoding. I haven't looked for a while so I'm not sure how much interface are now using them. - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
Hi, On Tue, Oct 11, 2011 at 3:42 PM, Julian Elischer wrote: > On 10/11/11 12:36 PM, Arnaud Lacombe wrote: >>> [...] >> libprocstat is _itself_ a problem: >> >> % git grep 'define _KERNEL' . >> [...] >> lib/libprocstat/cd9660.c:#define _KERNEL >> lib/libprocstat/nwfs.c:#define _KERNEL >> lib/libprocstat/smbfs.c:#define _KERNEL >> lib/libprocstat/udf.c:#define _KERNEL >> lib/libprocstat/zfs.c:#define _KERNEL >> [...] >> >> ok, I admit this is all FS related stuff :) > > but at least it comes with the system so it matches. > no, you should be able to run a FreeBSD 1.0 userland and a 9-RELEASE kernel together and have all utilities working. If not, you cannot claim to support backward compatibility, even if you do on a subset of kernel/userland interface. That said, this is just my personal opinion. > we've been looking for the 'right' way to do this since, hmmm, 1988 that I > remember and I bet before that too. > then the job was done bad. I will repeat myself here, but I ran what-was-to-become-Linux-v3.2 kernel on a 4 years old openwrt image and still had a functional system. Comparatively, I could not mix FreeBSD 7-STABLE userland and 8-STABLE kernel, The 8-STABLE kernel even changed the FS enough to make FreeBSD 7 unable to boot (even single user). Let me emphasize again that it is only my personal opinion :-) - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
On 10/11/11 12:36 PM, Arnaud Lacombe wrote: Hi, On Tue, Oct 11, 2011 at 3:21 PM, René Ladan wrote: 2011/10/11 Garrett Cooper: On Tue, Oct 11, 2011 at 10:55 AM, Larry Rosenman wrote: On Wed, 12 Oct 2011, Matt Thyer wrote: On Oct 12, 2011 3:25 AM, "Larry Rosenman" wrote: I didn't say bug for bug, just not generate stupid errors like the ffs one. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Chuck Swiger wrote: On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. That apparently means you won't support clang then, because it's not intended to be (or ever going to be) fully bug-for-bug "compatible" with GCC. In this case, at least, clang is reporting legitimate issues which should be fixed, even if folks continue to build lsof with GCC from now until the end of days. The elegant solution would be to avoid this problem altogether by re-implementation of lsof using interfaces into the kernel that provide the required information. bsdof anyone? lsof is PORTABLE and available on LOTS of platforms. We have fstat, but lsof can be used between differing OS's. We've also asked for Kernel interfaces before, but no one volunteered to make the KPI for them. I'm sure if someone(tm) (not me, insufficient knowledge) was to make interfaces for ALL that lsof needs, Vic would implement it as it would make his life easier. It would be nice in general if there were sysctls for accessing this data as even utilities in base have libkvm magic sprinkled around with pointer magic by default instead of using the sysctl analogs (I'm referring to ifconfig, netstat, etc), and as noted by some.. using libkvm on live memory could be potentially; the only valid usage I can really think of is when dealing with . What data does Vic need to grab from the kernel in order to get the file descriptor data? Just a quick note that FreeBSD 9 and later also have libprocstat which could be a nice interface. I haven't looked at the details yet though. libprocstat is _itself_ a problem: % git grep 'define _KERNEL' . [...] lib/libprocstat/cd9660.c:#define _KERNEL lib/libprocstat/nwfs.c:#define _KERNEL lib/libprocstat/smbfs.c:#define _KERNEL lib/libprocstat/udf.c:#define _KERNEL lib/libprocstat/zfs.c:#define _KERNEL [...] ok, I admit this is all FS related stuff :) but at least it comes with the system so it matches. we've been looking for the 'right' way to do this since, hmmm, 1988 that I remember and I bet before that too. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
Hi, On Tue, Oct 11, 2011 at 3:04 PM, Larry Rosenman wrote: > On 10/11/2011 1:52 PM, Arnaud Lacombe wrote: >> >> Hi, >> >> On Tue, Oct 11, 2011 at 2:39 PM, Larry Rosenman wrote: >>> >>> On 10/11/2011 1:36 PM, Arnaud Lacombe wrote: Hi, On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andric wrote: > > On 2011-10-09 19:32, Larry Rosenman wrote: >> >> I had gotten a PR about sysutils/lsof not compiling with clang. I had >> Vic Abell check it out, and the problem is NOT with lsof per se, but >> with the system headers. >> >> Is there a project afoot to update the system headers to make them >> clang >> compilable? > > The problem isn't that clang can't compile the system headers, but > normally these don't get included from userspace. And they certainly > won't work as expected when you define _KERNEL in userspace, as the > lsof > port foolishly does. It probably can't be avoided in such a tool, > though. > #ifdef _KERNEL/#endif protected part of system headers shall NEVER be accessed by userland. It is a fault to have them present in /usr/include. Linux got it right there, all those part are removed upon headers' installation. - Arnaud >>> >>> Then lsof would NOT be compilable / usable at all, as it delves into >>> /dev/kmem to get information. >>> >> AFAIK, Linux is capable of supporting lsof in a backward compatible >> manner, without exposing its internal guts. >> >> FWIW, KVM is a bad kernel/userland interface, as it does not guarantee >> backward compatibility. >> >>> And it **NEEDS** to know what the structures are. >>> >> No, not kernel-only structure. Now, if these structure are not meant >> to be kernel only, move them out of _KERNEL area, but beware of >> backward compatibility issue in the future. > > Therein lies the rub. In order to do it's job, it DOES need to grovel > around in kernel only structures. > > >> >>> That is unless someone(tm) writes the Kernel interfaces to get the info. >>> >> Yes, this is the core of the problem and a classical chicken/eggs >> problem solves the very wrongest way. >> >> At some point, I thought to modify the build system to pass kernel's >> headers through unifdef(1), but I quickly forgot about that: >> >> % git grep 'define _KERNEL' * | grep -v '^sys' | wc -l >> 27 >> >> - Arnaud > > This is not going to fix things until/unless someone(tm) takes the bull by > the horns, and writes > a userland<->kernel interface to get ALL the data that lsof currently > gathers from groveling around > in /dev/kmem. > > I don't have the skills nor time to do that. > What are those interfaces exactly ? How is it done in Linux ? Thanks, - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
Hi, On Tue, Oct 11, 2011 at 3:21 PM, René Ladan wrote: > 2011/10/11 Garrett Cooper : >> On Tue, Oct 11, 2011 at 10:55 AM, Larry Rosenman wrote: >>> On Wed, 12 Oct 2011, Matt Thyer wrote: >>> On Oct 12, 2011 3:25 AM, "Larry Rosenman" wrote: > > I didn't say bug for bug, just not generate stupid errors like the ffs one. > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > Chuck Swiger wrote: > > On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: >> >> We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. > > That apparently means you won't support clang then, because it's not intended to be (or ever going to be) fully bug-for-bug "compatible" with GCC. In this case, at least, clang is reporting legitimate issues which should be fixed, even if folks continue to build lsof with GCC from now until the end of days. The elegant solution would be to avoid this problem altogether by re-implementation of lsof using interfaces into the kernel that provide the required information. bsdof anyone? >>> lsof is PORTABLE and available on LOTS of platforms. >>> >>> We have fstat, but lsof can be used between differing OS's. >>> >>> We've also asked for Kernel interfaces before, but no one volunteered >>> to make the KPI for them. >>> >>> I'm sure if someone(tm) (not me, insufficient knowledge) was >>> to make interfaces for ALL that lsof needs, Vic would implement it >>> as it would make his life easier. >> >> It would be nice in general if there were sysctls for accessing this >> data as even utilities in base have libkvm magic sprinkled around with >> pointer magic by default instead of using the sysctl analogs (I'm >> referring to ifconfig, netstat, etc), and as noted by some.. using >> libkvm on live memory could be potentially; the only valid usage I can >> really think of is when dealing with . >> >> What data does Vic need to grab from the kernel in order to get the >> file descriptor data? >> > Just a quick note that FreeBSD 9 and later also have libprocstat which > could be a nice interface. I haven't looked at the details yet though. > libprocstat is _itself_ a problem: % git grep 'define _KERNEL' . [...] lib/libprocstat/cd9660.c:#define _KERNEL lib/libprocstat/nwfs.c:#define _KERNEL lib/libprocstat/smbfs.c:#define _KERNEL lib/libprocstat/udf.c:#define _KERNEL lib/libprocstat/zfs.c:#define _KERNEL [...] ok, I admit this is all FS related stuff :) - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
On Tue, Oct 11, 2011 at 11:36 AM, Arnaud Lacombe wrote: > Hi, > > On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andric wrote: >> On 2011-10-09 19:32, Larry Rosenman wrote: >>> >>> I had gotten a PR about sysutils/lsof not compiling with clang. I had >>> Vic Abell check it out, and the problem is NOT with lsof per se, but >>> with the system headers. >>> >>> Is there a project afoot to update the system headers to make them clang >>> compilable? >> >> The problem isn't that clang can't compile the system headers, but >> normally these don't get included from userspace. And they certainly >> won't work as expected when you define _KERNEL in userspace, as the lsof >> port foolishly does. It probably can't be avoided in such a tool, though. >> > #ifdef _KERNEL/#endif protected part of system headers shall NEVER be > accessed by userland. It is a fault to have them present in > /usr/include. Linux got it right there, all those part are removed > upon headers' installation. Yes, but instead Linux encourages mucking around with /proc and /sys, which have varying levels of formatting and provided output. The data needs to be exported properly via sysctl. If it's not done that way to userland, then the API/KPI is flawed and needs to be revised. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
On Tue, Oct 11, 2011 at 11:40 AM, Arnaud Lacombe wrote: > Hi, > > On Tue, Oct 11, 2011 at 9:51 AM, Dimitry Andric wrote: >> On 2011-10-11 15:31, Larry Rosenman wrote: >>> >>> On Tue, 11 Oct 2011, Dimitry Andric wrote: >> >> ... I've attached a fix for the lsof port, which also makes it build on 10.0-CURRENT (this was easy to fix here, as lsof uses its own hand-rolled configuration script). Let me know if it works for you. >>> Unless the headers are fixed, Vic Abell (lsof Author) will NOT support it. >>> >>> We need to get clang/system headers to allow warning free compilation >>> just like GCC does. >> >> The system headers compile without warning, if you use them as intended >> (e.g. from the kernel), which lsof obviously doesn't do. There is no >> easy workaround here, except by modifying lsof. >> >> For example, the warning about KASSERT is because lsof's headers don't >> include the required headers for this macro. And gcc is apparently not >> smart enough to generate warnings for this. :) >> > KASSERT() (from `sys/systm.h') is kernel only, any userland code > seeing it is not using the header properly. I'd be a strong proponent > of: > > #ifdef _KERNEL > #error "You are NOT meant to define _KERNEL in userland application" > #endif > > So this has nothing to do about smartness, but correctness. net-snmp suffers from this as well because it pokes around some kernel structures and data types to gather statistics related to IPv6, routing, etc in order to fulfill MIB-II compliance. Part of the bits are present, but not all of them, and I would really like for the need to muck around in _KERNEL to go away... Similarly, we have several utilities in base that muck around in _KERNEL that really shouldn't IMHO. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
2011/10/11 Garrett Cooper : > On Tue, Oct 11, 2011 at 10:55 AM, Larry Rosenman wrote: >> On Wed, 12 Oct 2011, Matt Thyer wrote: >> >>> On Oct 12, 2011 3:25 AM, "Larry Rosenman" wrote: I didn't say bug for bug, just not generate stupid errors like the ffs >>> >>> one. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Chuck Swiger wrote: On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: > > We will NOT support clang as the compiler for lsof unless the system >>> >>> headers work the same way as gcc's do. That apparently means you won't support clang then, because it's not >>> >>> intended to be (or ever going to be) fully bug-for-bug "compatible" with >>> GCC. In this case, at least, clang is reporting legitimate issues which >>> should be fixed, even if folks continue to build lsof with GCC from now >>> until the end of days. >>> >>> The elegant solution would be to avoid this problem altogether by >>> re-implementation of lsof using interfaces into the kernel that provide >>> the >>> required information. >>> >>> bsdof anyone? >>> >> lsof is PORTABLE and available on LOTS of platforms. >> >> We have fstat, but lsof can be used between differing OS's. >> >> We've also asked for Kernel interfaces before, but no one volunteered >> to make the KPI for them. >> >> I'm sure if someone(tm) (not me, insufficient knowledge) was >> to make interfaces for ALL that lsof needs, Vic would implement it >> as it would make his life easier. > > It would be nice in general if there were sysctls for accessing this > data as even utilities in base have libkvm magic sprinkled around with > pointer magic by default instead of using the sysctl analogs (I'm > referring to ifconfig, netstat, etc), and as noted by some.. using > libkvm on live memory could be potentially; the only valid usage I can > really think of is when dealing with . > > What data does Vic need to grab from the kernel in order to get the > file descriptor data? > Just a quick note that FreeBSD 9 and later also have libprocstat which could be a nice interface. I haven't looked at the details yet though. René ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
On Tue, Oct 11, 2011 at 10:55 AM, Larry Rosenman wrote: > On Wed, 12 Oct 2011, Matt Thyer wrote: > >> On Oct 12, 2011 3:25 AM, "Larry Rosenman" wrote: >>> >>> I didn't say bug for bug, just not generate stupid errors like the ffs >> >> one. >>> >>> -- >>> Sent from my Android phone with K-9 Mail. Please excuse my brevity. >>> >>> Chuck Swiger wrote: >>> >>> On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: We will NOT support clang as the compiler for lsof unless the system >> >> headers work the same way as gcc's do. >>> >>> That apparently means you won't support clang then, because it's not >> >> intended to be (or ever going to be) fully bug-for-bug "compatible" with >> GCC. In this case, at least, clang is reporting legitimate issues which >> should be fixed, even if folks continue to build lsof with GCC from now >> until the end of days. >> >> The elegant solution would be to avoid this problem altogether by >> re-implementation of lsof using interfaces into the kernel that provide >> the >> required information. >> >> bsdof anyone? >> > lsof is PORTABLE and available on LOTS of platforms. > > We have fstat, but lsof can be used between differing OS's. > > We've also asked for Kernel interfaces before, but no one volunteered > to make the KPI for them. > > I'm sure if someone(tm) (not me, insufficient knowledge) was > to make interfaces for ALL that lsof needs, Vic would implement it > as it would make his life easier. It would be nice in general if there were sysctls for accessing this data as even utilities in base have libkvm magic sprinkled around with pointer magic by default instead of using the sysctl analogs (I'm referring to ifconfig, netstat, etc), and as noted by some.. using libkvm on live memory could be potentially; the only valid usage I can really think of is when dealing with . What data does Vic need to grab from the kernel in order to get the file descriptor data? Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
On 10/11/2011 1:52 PM, Arnaud Lacombe wrote: Hi, On Tue, Oct 11, 2011 at 2:39 PM, Larry Rosenman wrote: On 10/11/2011 1:36 PM, Arnaud Lacombe wrote: Hi, On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andricwrote: On 2011-10-09 19:32, Larry Rosenman wrote: I had gotten a PR about sysutils/lsof not compiling with clang. I had Vic Abell check it out, and the problem is NOT with lsof per se, but with the system headers. Is there a project afoot to update the system headers to make them clang compilable? The problem isn't that clang can't compile the system headers, but normally these don't get included from userspace. And they certainly won't work as expected when you define _KERNEL in userspace, as the lsof port foolishly does. It probably can't be avoided in such a tool, though. #ifdef _KERNEL/#endif protected part of system headers shall NEVER be accessed by userland. It is a fault to have them present in /usr/include. Linux got it right there, all those part are removed upon headers' installation. - Arnaud Then lsof would NOT be compilable / usable at all, as it delves into /dev/kmem to get information. AFAIK, Linux is capable of supporting lsof in a backward compatible manner, without exposing its internal guts. FWIW, KVM is a bad kernel/userland interface, as it does not guarantee backward compatibility. And it **NEEDS** to know what the structures are. No, not kernel-only structure. Now, if these structure are not meant to be kernel only, move them out of _KERNEL area, but beware of backward compatibility issue in the future. Therein lies the rub. In order to do it's job, it DOES need to grovel around in kernel only structures. That is unless someone(tm) writes the Kernel interfaces to get the info. Yes, this is the core of the problem and a classical chicken/eggs problem solves the very wrongest way. At some point, I thought to modify the build system to pass kernel's headers through unifdef(1), but I quickly forgot about that: % git grep 'define _KERNEL' * | grep -v '^sys' | wc -l 27 - Arnaud This is not going to fix things until/unless someone(tm) takes the bull by the horns, and writes a userland<->kernel interface to get ALL the data that lsof currently gathers from groveling around in /dev/kmem. I don't have the skills nor time to do that. We can go around and around on this topic, but until/unless either the clang headers/built-ins are changed to match the system/kernel headers, or someone(tm) writes the interfaces, clang will NOT be supported to compile sysutils/lsof. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
Hi, On Tue, Oct 11, 2011 at 2:39 PM, Larry Rosenman wrote: > On 10/11/2011 1:36 PM, Arnaud Lacombe wrote: >> >> Hi, >> >> On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andric wrote: >>> >>> On 2011-10-09 19:32, Larry Rosenman wrote: I had gotten a PR about sysutils/lsof not compiling with clang. I had Vic Abell check it out, and the problem is NOT with lsof per se, but with the system headers. Is there a project afoot to update the system headers to make them clang compilable? >>> >>> The problem isn't that clang can't compile the system headers, but >>> normally these don't get included from userspace. And they certainly >>> won't work as expected when you define _KERNEL in userspace, as the lsof >>> port foolishly does. It probably can't be avoided in such a tool, >>> though. >>> >> #ifdef _KERNEL/#endif protected part of system headers shall NEVER be >> accessed by userland. It is a fault to have them present in >> /usr/include. Linux got it right there, all those part are removed >> upon headers' installation. >> >> - Arnaud > > Then lsof would NOT be compilable / usable at all, as it delves into > /dev/kmem to get information. > AFAIK, Linux is capable of supporting lsof in a backward compatible manner, without exposing its internal guts. FWIW, KVM is a bad kernel/userland interface, as it does not guarantee backward compatibility. > And it **NEEDS** to know what the structures are. > No, not kernel-only structure. Now, if these structure are not meant to be kernel only, move them out of _KERNEL area, but beware of backward compatibility issue in the future. > That is unless someone(tm) writes the Kernel interfaces to get the info. > Yes, this is the core of the problem and a classical chicken/eggs problem solves the very wrongest way. At some point, I thought to modify the build system to pass kernel's headers through unifdef(1), but I quickly forgot about that: % git grep 'define _KERNEL' * | grep -v '^sys' | wc -l 27 - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
Hi, On Tue, Oct 11, 2011 at 9:51 AM, Dimitry Andric wrote: > On 2011-10-11 15:31, Larry Rosenman wrote: >> >> On Tue, 11 Oct 2011, Dimitry Andric wrote: > > ... >>> >>> I've attached a fix for the lsof port, which also makes it build on >>> 10.0-CURRENT (this was easy to fix here, as lsof uses its own >>> hand-rolled configuration script). Let me know if it works for you. >>> >> Unless the headers are fixed, Vic Abell (lsof Author) will NOT support it. >> >> We need to get clang/system headers to allow warning free compilation >> just like GCC does. > > The system headers compile without warning, if you use them as intended > (e.g. from the kernel), which lsof obviously doesn't do. There is no > easy workaround here, except by modifying lsof. > > For example, the warning about KASSERT is because lsof's headers don't > include the required headers for this macro. And gcc is apparently not > smart enough to generate warnings for this. :) > KASSERT() (from `sys/systm.h') is kernel only, any userland code seeing it is not using the header properly. I'd be a strong proponent of: #ifdef _KERNEL #error "You are NOT meant to define _KERNEL in userland application" #endif So this has nothing to do about smartness, but correctness. - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
On 10/11/2011 1:36 PM, Arnaud Lacombe wrote: Hi, On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andric wrote: On 2011-10-09 19:32, Larry Rosenman wrote: I had gotten a PR about sysutils/lsof not compiling with clang. I had Vic Abell check it out, and the problem is NOT with lsof per se, but with the system headers. Is there a project afoot to update the system headers to make them clang compilable? The problem isn't that clang can't compile the system headers, but normally these don't get included from userspace. And they certainly won't work as expected when you define _KERNEL in userspace, as the lsof port foolishly does. It probably can't be avoided in such a tool, though. #ifdef _KERNEL/#endif protected part of system headers shall NEVER be accessed by userland. It is a fault to have them present in /usr/include. Linux got it right there, all those part are removed upon headers' installation. - Arnaud Then lsof would NOT be compilable / usable at all, as it delves into /dev/kmem to get information. And it **NEEDS** to know what the structures are. That is unless someone(tm) writes the Kernel interfaces to get the info. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
Hi, On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andric wrote: > On 2011-10-09 19:32, Larry Rosenman wrote: >> >> I had gotten a PR about sysutils/lsof not compiling with clang. I had >> Vic Abell check it out, and the problem is NOT with lsof per se, but >> with the system headers. >> >> Is there a project afoot to update the system headers to make them clang >> compilable? > > The problem isn't that clang can't compile the system headers, but > normally these don't get included from userspace. And they certainly > won't work as expected when you define _KERNEL in userspace, as the lsof > port foolishly does. It probably can't be avoided in such a tool, though. > #ifdef _KERNEL/#endif protected part of system headers shall NEVER be accessed by userland. It is a fault to have them present in /usr/include. Linux got it right there, all those part are removed upon headers' installation. - Arnaud ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
On Wed, 12 Oct 2011, Matt Thyer wrote: On Oct 12, 2011 3:25 AM, "Larry Rosenman" wrote: I didn't say bug for bug, just not generate stupid errors like the ffs one. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Chuck Swiger wrote: On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. That apparently means you won't support clang then, because it's not intended to be (or ever going to be) fully bug-for-bug "compatible" with GCC. In this case, at least, clang is reporting legitimate issues which should be fixed, even if folks continue to build lsof with GCC from now until the end of days. The elegant solution would be to avoid this problem altogether by re-implementation of lsof using interfaces into the kernel that provide the required information. bsdof anyone? lsof is PORTABLE and available on LOTS of platforms. We have fstat, but lsof can be used between differing OS's. We've also asked for Kernel interfaces before, but no one volunteered to make the KPI for them. I'm sure if someone(tm) (not me, insufficient knowledge) was to make interfaces for ALL that lsof needs, Vic would implement it as it would make his life easier. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: > We will NOT support clang as the compiler for lsof unless the system headers > work the same way as gcc's do. That apparently means you won't support clang then, because it's not intended to be (or ever going to be) fully bug-for-bug "compatible" with GCC. In this case, at least, clang is reporting legitimate issues which should be fixed, even if folks continue to build lsof with GCC from now until the end of days. To echo a word someone else just used, I'm baffled as to why you would hold such a position. Regards, -- -Chuck ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
On Oct 12, 2011 3:25 AM, "Larry Rosenman" wrote: > > I didn't say bug for bug, just not generate stupid errors like the ffs one. > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > > Chuck Swiger wrote: > > On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: > > We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. > > That apparently means you won't support clang then, because it's not intended to be (or ever going to be) fully bug-for-bug "compatible" with GCC. In this case, at least, clang is reporting legitimate issues which should be fixed, even if folks continue to build lsof with GCC from now until the end of days. The elegant solution would be to avoid this problem altogether by re-implementation of lsof using interfaces into the kernel that provide the required information. bsdof anyone? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
I didn't say bug for bug, just not generate stupid errors like the ffs one. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Chuck Swiger wrote: On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: > We will NOT support clang as the compiler for lsof unless the system headers > work the same way as gcc's do. That apparently means you won't support clang then, because it's not intended to be (or ever going to be) fully bug-for-bug "compatible" with GCC. In this case, at least, clang is reporting legitimate issues which should be fixed, even if folks continue to build lsof with GCC from now until the end of days. To echo a word someone else just used, I'm baffled as to why you would hold such a position. Regards, -- -Chuck ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
On Tue, 11 Oct 2011, Kevin Oberman wrote: On Tue, Oct 11, 2011 at 6:59 AM, Larry Rosenman wrote: On 10/11/2011 8:51 AM, Dimitry Andric wrote: On 2011-10-11 15:31, Larry Rosenman wrote: On Tue, 11 Oct 2011, Dimitry Andric wrote: ... I've attached a fix for the lsof port, which also makes it build on 10.0-CURRENT (this was easy to fix here, as lsof uses its own hand-rolled configuration script). Let me know if it works for you. Unless the headers are fixed, Vic Abell (lsof Author) will NOT support it. We need to get clang/system headers to allow warning free compilation just like GCC does. The system headers compile without warning, if you use them as intended (e.g. from the kernel), which lsof obviously doesn't do. There is no easy workaround here, except by modifying lsof. For example, the warning about KASSERT is because lsof's headers don't include the required headers for this macro. And gcc is apparently not smart enough to generate warnings for this. :) In any case, isn't lsof's dlsof.h header full of special cases already? What does it matter to add another one? Besides, even if you fix it in the system headers now, at compile time you cannot be sure if the user has the correct version of them installed anyway, so you would still have to work around the problem. We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. Period. Are asking that clang become bug compatible with gcc or that gcc be fixed to present the same errors as clang does? As a casual observer I really don't expect either to happen soon. (I suspect gcc being fixed SLIGHTLY more likely.) No, just asking that the same headers not generate ERRORS where gcc doesn't Extra Warnings are fine. the big one here is the _builtin_ffs() one about signed vs unsigned. By it's very nature lsof does a lot of the sort of kernel interaction that is normally considered to be unacceptable and requires lots of kludges and hacks to do them. I am simply baffled as to why this issue is so different other then that it is dependent on the compiler used and not the differences between kernels and kernel interfaces. It's not. It's just that this seems(!) to be a trivial issue to fix for the folks adding/wanting clang to process all ports. On the other hand, I have not done real kernel programming in years...not since I was writing kernel code in assembly for VMS about 20 years ago, so maybe I am missing some subtleties about this. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
On Tue, Oct 11, 2011 at 6:59 AM, Larry Rosenman wrote: > On 10/11/2011 8:51 AM, Dimitry Andric wrote: >> >> On 2011-10-11 15:31, Larry Rosenman wrote: >>> >>> On Tue, 11 Oct 2011, Dimitry Andric wrote: >> >> ... I've attached a fix for the lsof port, which also makes it build on 10.0-CURRENT (this was easy to fix here, as lsof uses its own hand-rolled configuration script). Let me know if it works for you. >>> Unless the headers are fixed, Vic Abell (lsof Author) will NOT support >>> it. >>> >>> We need to get clang/system headers to allow warning free compilation >>> just like GCC does. >> >> The system headers compile without warning, if you use them as intended >> (e.g. from the kernel), which lsof obviously doesn't do. There is no >> easy workaround here, except by modifying lsof. >> >> For example, the warning about KASSERT is because lsof's headers don't >> include the required headers for this macro. And gcc is apparently not >> smart enough to generate warnings for this. :) >> >> In any case, isn't lsof's dlsof.h header full of special cases already? >> What does it matter to add another one? >> >> Besides, even if you fix it in the system headers now, at compile time >> you cannot be sure if the user has the correct version of them installed >> anyway, so you would still have to work around the problem. > > We will NOT support clang as the compiler for lsof unless the system headers > work the same way as gcc's do. > > Period. Are asking that clang become bug compatible with gcc or that gcc be fixed to present the same errors as clang does? As a casual observer I really don't expect either to happen soon. (I suspect gcc being fixed SLIGHTLY more likely.) By it's very nature lsof does a lot of the sort of kernel interaction that is normally considered to be unacceptable and requires lots of kludges and hacks to do them. I am simply baffled as to why this issue is so different other then that it is dependent on the compiler used and not the differences between kernels and kernel interfaces. On the other hand, I have not done real kernel programming in years...not since I was writing kernel code in assembly for VMS about 20 years ago, so maybe I am missing some subtleties about this. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
On 10/11/2011 8:51 AM, Dimitry Andric wrote: On 2011-10-11 15:31, Larry Rosenman wrote: On Tue, 11 Oct 2011, Dimitry Andric wrote: ... I've attached a fix for the lsof port, which also makes it build on 10.0-CURRENT (this was easy to fix here, as lsof uses its own hand-rolled configuration script). Let me know if it works for you. Unless the headers are fixed, Vic Abell (lsof Author) will NOT support it. We need to get clang/system headers to allow warning free compilation just like GCC does. The system headers compile without warning, if you use them as intended (e.g. from the kernel), which lsof obviously doesn't do. There is no easy workaround here, except by modifying lsof. For example, the warning about KASSERT is because lsof's headers don't include the required headers for this macro. And gcc is apparently not smart enough to generate warnings for this. :) In any case, isn't lsof's dlsof.h header full of special cases already? What does it matter to add another one? Besides, even if you fix it in the system headers now, at compile time you cannot be sure if the user has the correct version of them installed anyway, so you would still have to work around the problem. We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. Period. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
On 2011-10-11 15:31, Larry Rosenman wrote: On Tue, 11 Oct 2011, Dimitry Andric wrote: ... I've attached a fix for the lsof port, which also makes it build on 10.0-CURRENT (this was easy to fix here, as lsof uses its own hand-rolled configuration script). Let me know if it works for you. Unless the headers are fixed, Vic Abell (lsof Author) will NOT support it. We need to get clang/system headers to allow warning free compilation just like GCC does. The system headers compile without warning, if you use them as intended (e.g. from the kernel), which lsof obviously doesn't do. There is no easy workaround here, except by modifying lsof. For example, the warning about KASSERT is because lsof's headers don't include the required headers for this macro. And gcc is apparently not smart enough to generate warnings for this. :) In any case, isn't lsof's dlsof.h header full of special cases already? What does it matter to add another one? Besides, even if you fix it in the system headers now, at compile time you cannot be sure if the user has the correct version of them installed anyway, so you would still have to work around the problem. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
On Tue, 11 Oct 2011, Dimitry Andric wrote:
On 2011-10-09 19:32, Larry Rosenman wrote:
I had gotten a PR about sysutils/lsof not compiling with clang. I had
Vic Abell check it out, and the problem is NOT with lsof per se, but
with the system headers.
Is there a project afoot to update the system headers to make them clang
compilable?
The problem isn't that clang can't compile the system headers, but
normally these don't get included from userspace. And they certainly
won't work as expected when you define _KERNEL in userspace, as the lsof
port foolishly does. It probably can't be avoided in such a tool, though.
...
In file included from ckkv.c:43:
In file included from ./../lsof.h:195:
In file included from ./../dlsof.h:190:
In file included from /usr/src/sys/ufs/ufs/ufsmount.h:36:
/usr/src/sys/sys/buf.h:388:2: warning: implicit declaration of function
'KASSERT' is invalid in C99
[-Wimplicit-function-declaration]
KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p", bp));
^
/usr/src/sys/sys/buf.h:388:33: warning: expression result unused
[-Wunused-value]
KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p", bp));
^
These are more or less harmless warnings, as long as nobody calls a
function that uses KASSERT. They occur because lsof's headers don't
include and before .
...
In file included from ckkv.c:43:
In file included from ./../lsof.h:195:
In file included from ./../dlsof.h:432:
In file included from /usr/include/string.h:45:
/usr/include/strings.h:47:6: error: conflicting types for '__builtin_ffs'
int ffs(int) __pure2;
^
/usr/include/machine/cpufunc.h:140:24: note: expanded from:
#defineffs(x) __builtin_ffs(x)
^
/usr/include/strings.h:47:6: note: '__builtin_ffs' is a builtin with type
'int (unsigned int)'
This is because the amd64 system headers redefine ffs to __builtin_ffs,
after which it conflicts with the declaration in /usr/include/strings.h.
On i386, ffs is not redefined, but I have no idea why.
In any case, gcc does not complain about the incompatible redeclaration,
which may be a bug, or just stupid luck, depending on your POV. :)
I've attached a fix for the lsof port, which also makes it build on
10.0-CURRENT (this was easy to fix here, as lsof uses its own
hand-rolled configuration script). Let me know if it works for you.
Unless the headers are fixed, Vic Abell (lsof Author) will NOT support it.
We need to get clang/system headers to allow warning free compilation
just like GCC does.
I will NOT accept the change.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: l...@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3893
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: System headers with clang?
On 2011-10-09 19:32, Larry Rosenman wrote:
I had gotten a PR about sysutils/lsof not compiling with clang. I had
Vic Abell check it out, and the problem is NOT with lsof per se, but
with the system headers.
Is there a project afoot to update the system headers to make them clang
compilable?
The problem isn't that clang can't compile the system headers, but
normally these don't get included from userspace. And they certainly
won't work as expected when you define _KERNEL in userspace, as the lsof
port foolishly does. It probably can't be avoided in such a tool, though.
...
In file included from ckkv.c:43:
In file included from ./../lsof.h:195:
In file included from ./../dlsof.h:190:
In file included from /usr/src/sys/ufs/ufs/ufsmount.h:36:
/usr/src/sys/sys/buf.h:388:2: warning: implicit declaration of function
'KASSERT' is invalid in C99
[-Wimplicit-function-declaration]
KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p", bp));
^
/usr/src/sys/sys/buf.h:388:33: warning: expression result unused
[-Wunused-value]
KASSERT(bp->b_bufobj != NULL, ("bwrite: no bufobj bp=%p", bp));
^
These are more or less harmless warnings, as long as nobody calls a
function that uses KASSERT. They occur because lsof's headers don't
include and before .
...
In file included from ckkv.c:43:
In file included from ./../lsof.h:195:
In file included from ./../dlsof.h:432:
In file included from /usr/include/string.h:45:
/usr/include/strings.h:47:6: error: conflicting types for '__builtin_ffs'
int ffs(int) __pure2;
^
/usr/include/machine/cpufunc.h:140:24: note: expanded from:
#defineffs(x) __builtin_ffs(x)
^
/usr/include/strings.h:47:6: note: '__builtin_ffs' is a builtin with type 'int
(unsigned int)'
This is because the amd64 system headers redefine ffs to __builtin_ffs,
after which it conflicts with the declaration in /usr/include/strings.h.
On i386, ffs is not redefined, but I have no idea why.
In any case, gcc does not complain about the incompatible redeclaration,
which may be a bug, or just stupid luck, depending on your POV. :)
I've attached a fix for the lsof port, which also makes it build on
10.0-CURRENT (this was easy to fix here, as lsof uses its own
hand-rolled configuration script). Let me know if it works for you.
Index: sysutils/lsof/files/patch-Configure
===
RCS file: sysutils/lsof/files/patch-Configure
diff -N sysutils/lsof/files/patch-Configure
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sysutils/lsof/files/patch-Configure 11 Oct 2011 11:44:44 -
@@ -0,0 +1,72 @@
+--- Configure.orig 2011-08-15 18:15:56.0 +0200
Configure 2011-10-11 13:30:37.0 +0200
+@@ -1428,7 +1428,7 @@
+ 3.5*)
+ LSOF_VERS=3050
+ ;;
+- 3*)
++ 3.*)
+ LSOF_VERS=3050
+ echo "!!!WARNING!!! Unsupported FreeBSD version: $LSOF_VSTR"
+ echo "!!!WARNING!!! Configuring for FreeBSD 3.5"
+@@ -1481,7 +1481,7 @@
+ LSOF_TSTBIGF=" "
+ LSOF_VERS=4110
+ ;;
+- 4*)
++ 4.*)
+ LSOF_VERS=4100
+ echo "!!!WARNING!!! Unsupported FreeBSD version: $LSOF_VSTR"
+ echo "!!!WARNING!!! Configuring for FreeBSD 4.10"
+@@ -1510,7 +1510,7 @@
+ LSOF_TSTBIGF=" "
+ LSOF_VERS=5050
+ ;;
+- 5*)
++ 5.*)
+ LSOF_VERS=5050
+ echo "!!!WARNING!!! Unsupported FreeBSD version: $LSOF_VSTR"
+ echo "!!!WARNING!!! Configuring for FreeBSD 5.5"
+@@ -1535,7 +1535,7 @@
+ LSOF_TSTBIGF=" "
+ LSOF_VERS=6040
+ ;;
+- 6*)
++ 6.*)
+ LSOF_VERS=6000
+ echo "!!!WARNING!!! Unsupported FreeBSD version: $LSOF_VSTR"
+ echo "!!!WARNING!!! Configuring for FreeBSD 6.0"
+@@ -1560,7 +1560,7 @@
+ LSOF_TSTBIGF=" "
+ LSOF_VERS=7040
+ ;;
+- 7*)
++ 7.*)
+ LSOF_VERS=7000
+ echo "!!!WARNING!!! Unsupported FreeBSD version: $LSOF_VSTR"
+ echo "!!!WARNING!!! Configuring for FreeBSD 7.0"
+@@ -1577,10 +1577,14 @@
+ LSOF_TSTBIGF=" "
+ LSOF_VERS=8020
+ ;;
+- 9*)
++ 9.*)
+ LSOF_TSTBIGF=" "
+ LSOF_VERS=9000
+ ;;
++ 10.*)
++ LSOF_TSTBIGF=" "
++ LSOF_VERS=1
++ ;;
+ *)
+ echo Unknown FreeBSD release: `uname -r`
+ echo Assuming FreeBSD 2.x
+@@ -1684,7 +1688,7 @@
+ LSOF_CFGF="$LSOF_CFGF -DHASVMLOCKH"
+ fi # }
+ ;;
+-
4000|4010|4020|4030|4040|4050|4060|4070|4080|4090|4100|4110|5000|5010|5020|5030|5040|5050|6000|6010|6020|6030|6040|7000|7010|7020|7030|7040|8000|8010|8020|9000)
++
4000|4010|4020|4030|4040|4050|4060|4070|4080|4090|4100|4110|5000|5010|5020|5030|5040|5050|6000|6010|6020|6030|6040|7000|7010|7020|7030|7040|8000|8010|8020|9000|1)
+ if test -r ${LSOF_INCLUDE}/nfs/rpcv2.h # {
+ then
+ LSOF_CFGF="$LSOF_C
Re: System headers with clang?
2011/10/9 Larry Rosenman : > I had gotten a PR about sysutils/lsof not compiling with clang. That could be mine, ports/160544 ? > I had > Vic Abell check it out, and the problem is NOT with lsof per se, but > with the system headers. > > Is there a project afoot to update the system headers to make them clang > compilable? > So I get the same errors as you for 9.0 (also with BETA3) on amd64, but for 9.0 on i386 from 2011-08-19 it builds fine: http://rene-ladan.nl:8080/tb/logs/9-FreeBSD-clang/lsof-4.85D_1,5.log René ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
