Re: RFT: Please help testing the llvm/clang 3.5.0 import
On 18 Dec 2014, at 02:17, NGie Cooper yaneurab...@gmail.com wrote: On Fri, Nov 28, 2014 at 1:03 PM, Dimitry Andric d...@freebsd.org wrote: ... As a request to speed up the build process further, - Would it be [easily] possible in the clang35 branch to bootstrap the compiler for a specific architecture? The bootstrap / cross compiler for instance always builds N targets instead of building just the desired TARGET/TARGET_ARCH combo. It's not very easy, at least not without breaking various parts of our fragile build system, but I surely want to put something like this on the TODO list for *after* the import has completed. The branch is making progress right now, and I would not want to complicate matters further by introducing yet another tricky feature. :) - Could a MK_CLANG_ALL_TARGETS or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a cross-compile toolchain every iteration for our target MACHINE/MACHINE_ARCH? I would be fine with something like this, as long as it is turned off by default, or if it is only used for the bootstrap stages. It is actually an extremely useful feature of clang that you can target multiple architectures with one compiler binary. A more interesting case would be to remodel the build system so it can use one toolchain (external, or pkg-ng'd, maybe?) for building an entire universe. With clang, that should be relatively easy to do. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: RFT: Please help testing the llvm/clang 3.5.0 import
Dimitry Andric writes: - Could a MK_CLANG_ALL_TARGETS or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a cross-compile toolchain every iteration for our target MACHINE/MACHINE_ARCH? I would be fine with something like this, as long as it is turned off by default, or if it is only used for the bootstrap stages. It is actually an extremely useful feature of clang that you can target multiple architectures with one compiler binary. Point of information: this seems useful for developers, and (almost entirely) useless for everyone else. Are there other cohorts that want this badly? If that's correct, and there's a simple switch for configuration ... why should this default to what's useful for the (much?) smaller number of people? About what am I ignorant? Curiously, Robert Huff ___ 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
wrapping a vararg C function (specifically, log() in the kernel)
Hi, in the porting of some kernel code to FreeBSD, i need to remap one function with a variable number of arguments to the log() function from the freebsd kernel. Normally i would do #define WARN(x, args...)log(LOG_WARNING, args) but this does not work in my case because the function is called in (many) blocks where there is already a local variable with the same name bool log; which is used a ton of times. I was wondering if there is some C compiler magic i can use to do the remapping without going through a macro; I haven't found any direct one, though perhaps something like extern void (*freebsd_log)(int level, const char *fmt, ...); #define WARN(x, args...)freebsd_log(LOG_WARNING, args) followed somewhere in a safe place by freebsd_log = log; may do the job. Any other option ? cheers luigi ___ 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: RFT: Please help testing the llvm/clang 3.5.0 import
On Dec 18, 2014, at 6:34 AM, owner-freebsd-...@freebsd.org wrote: Dimitry Andric writes: - Could a MK_CLANG_ALL_TARGETS or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a cross-compile toolchain every iteration for our target MACHINE/MACHINE_ARCH? I would be fine with something like this, as long as it is turned off by default, or if it is only used for the bootstrap stages. It is actually an extremely useful feature of clang that you can target multiple architectures with one compiler binary. Point of information: this seems useful for developers, and (almost entirely) useless for everyone else. Are there other cohorts that want this badly? If that's correct, and there's a simple switch for configuration ... why should this default to what's useful for the (much?) smaller number of people? About what am I ignorant? Only people working on a single binary of clang to build all architectures are interested, which is a vanishingly small number. There’s little point to build this stuff even for hard-core developers. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: wrapping a vararg C function (specifically, log() in the kernel)
On Thu, 2014-12-18 at 15:21 +0100, Luigi Rizzo wrote:
Hi,
in the porting of some kernel code to FreeBSD, i need to remap one
function with a variable number of arguments to the log() function
from the freebsd kernel.
Normally i would do
#define WARN(x, args...)log(LOG_WARNING, args)
but this does not work in my case because the function is called in
(many) blocks where there is already a local variable with the same name
bool log;
which is used a ton of times.
I was wondering if there is some C compiler magic i can use to do the
remapping without going through a macro; I haven't found any direct one,
though perhaps something like
extern void (*freebsd_log)(int level, const char *fmt, ...);
#define WARN(x, args...)freebsd_log(LOG_WARNING, args)
followed somewhere in a safe place by
freebsd_log = log;
may do the job.
Any other option ?
cheers
luigi
Normally I'd fix it like:
#define WARN(x,args...) locallog(LOG_WARNING, args)
static inline void
locallog(int lvl, const char *fmt, ...)
{
va_list ap;
va_start(ap, fmt);
logv(level, fmt, ap);
va_end(ap);
}
But unfortunately we don't have a logv() function. I think maybe we
should have one. :)
-- Ian
___
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: RFT: Please help testing the llvm/clang 3.5.0 import
On 18 Dec 2014, at 14:34, Robert Huff wrote: Dimitry Andric writes: - Could a MK_CLANG_ALL_TARGETS or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a cross-compile toolchain every iteration for our target MACHINE/MACHINE_ARCH? I would be fine with something like this, as long as it is turned off by default, or if it is only used for the bootstrap stages. It is actually an extremely useful feature of clang that you can target multiple architectures with one compiler binary. Point of information: this seems useful for developers, and (almost entirely) useless for everyone else. Are there other cohorts that want this badly? If that's correct, and there's a simple switch for configuration ... why should this default to what's useful for the (much?) smaller number of people? About what am I ignorant? It's not a simple switch, at least not now. If you use the upstream build system for llvm, e.g. autoconf or CMake, it has an option to select all the architectures that are supported. Several config files are then generated differently, and parts of the target support subdirectories are selectively enabled or disabled. In fact, we already build just a subset of the available architectures, since FreeBSD only supports about 5 of them. We can probably arrange for a more minimal configuration in our build system, but since the build time saved is quite small, I don't think it makes much sense in complicating our build system even further. If people are really so interested in shaving off a little, for more complication, that is fine with me. But unfortunately, I have too many tasks on my plate right now, and I cannot work on it. Besides, doing such a new feature now would interfere with the current branch work. Also, after the 3.5.0 import, there are much more interesting fish to fry, in my opinion. For example, importing newer versions of libc++ and compiler-rt, which can bring address sanitizer support, etc. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: RFT: Please help testing the llvm/clang 3.5.0 import
This is excellent news Dimitry! On Dec 16, 2014, at 12:36 PM, Dimitry Andric d...@freebsd.org wrote: On 28 Nov 2014, at 22:03, Dimitry Andric d...@freebsd.org wrote: We're working on updating llvm, clang and lldb to 3.5.0 in head. This is quite a big update again, and any help with testing is appreciated. To try this out, ensure you have good backups or snapshots, then build world and kernel from the projects/clang350-import branch [1]. Please use a Subversion mirror [2], if you are able to. Here are some updates about the status of the 3.5.0 import. * i386 and amd64 have been tested through make universe, and everything should compile and run. * Little-endian ARM builds should now compile and run, thanks to Andrew Turner for putting in lots of work. * Big-endian ARM is apparently supposed to work, but I'm not sure if Andrew managed to test it on real hardware. I know Andrew doesn’t have the right arm gear to do this test, and emulation environments that run FreeBSD have had poor big-endian support for arm. * PowerPC64 should mostly work, thanks to Justin Hibbits. * PowerPC32 might start working soon; it really needs some backporting of fixes to clang 3.4.1, which is now in head, so there is an easier upgrade path for PowerPC users. * Sparc64 still does not work, and I don't see any quick solutions to it for now. It should probably stay with gcc. * Mips will only have a chance with the upcoming clang 3.6.0, but that is way too late for this import. It will probably require external toolchain support to get it working. For native builds yes. For cross builds, clang 3.6 can be built on an x86 host. * Another ports exp-run was done [3], after fixing the problem with lang/gcc, which lead to many skipped dependent ports. * The second exp-run had much better results: the failure with the highest number of dependencies is devel/mingw32-gcc, but this seems to be due to a problem with makeinfo, not clang. The next highest on the list is java/openjdk6, for which ports r374780 [4] was very recently committed. Will users of our stable branch have code similar to the code that caused problems? One warning flag about your upgrade to the stable branch would be if there’s a significant number of user-written programs that suddenly become uncompilable with the new clang using the environment that they have today. We know of some items that are issues, so careful attention here is needed. Unless we go proactively looking for these, there’s a good chance we won’t find them until users hit them and start to complain (by which point it is likely too late). Could you post a summary of the issues that ports have hit and the fixes necessary? We may need to have that in the release notes and/or UPDATING file to help prepare our users for the bumps and give them solutions over them. I would really like to merge this branch to head in about a week, pending portmgr approvall; I don't expect the base system (outside of llvm/clang) to need any further updates. I think there’s good reason to do this, but we should chat about the build issues below before doing it. They are minor, but an important detail. I’ll see if I can find a few minutes to pull the branch and send patches. Lastly, to clear things up about the requirements for this branch (and thus for head, in a while); to build it, you need to have: * A C++11 capable host compiler, e.g. clang = 3.3 or later, or gcc = 4.8 (I'm not 100% sure if gcc 4.7 will work, reports welcome) * A C++11 standard library, e.g. libc++, or libstdc++ from gcc = 4.8. So from any earlier standard 10.x or 11.x installation, you should be good, unless you explicitly disabled clang or libc++. In that case, you must build and install both of those first. This is true only on i386, amd64, and arm hosts. Given that some people do try to do weird things, tightening up how you present this will get the word out a little better. On a 9.x installation, you will have clang by default, but not libc++, so libc++ should be built and installed first, before attempting to build the clang350-import branch. Can you make sure that the UPDATING entry you are writing for this contains explicit instructions. On 8.x an earlier, you need to upgrade to at least 9.x first, follow the previous instruction. We should remove building on 8 support then, unless there external toolchain stuff is up to the task (e.g. build gcc 4.9, libstc++, etc). As for MFC'ing, I plan on merging clang 3.5.x to 10.x in a while (roughly a month), but this will cause upgrades from 9.x to 10.x to start requiring the build of libc++, as described above. I don't think we can merge clang 3.5.x to 9.x, unless clang becomes the default compiler there (but that is very unlikely). Let’s see how it goes, and what the upgrade issues wind up being before doing this merge back. New “major” compilers on stable branches traditionally haven’t been done, but if clang is
Re: RFT: Please help testing the llvm/clang 3.5.0 import
On Dec 18, 2014, at 6:02 AM, Dimitry Andric d...@freebsd.org wrote: On 18 Dec 2014, at 02:17, NGie Cooper yaneurab...@gmail.com wrote: On Fri, Nov 28, 2014 at 1:03 PM, Dimitry Andric d...@freebsd.org wrote: ... As a request to speed up the build process further, - Would it be [easily] possible in the clang35 branch to bootstrap the compiler for a specific architecture? The bootstrap / cross compiler for instance always builds N targets instead of building just the desired TARGET/TARGET_ARCH combo. It's not very easy, at least not without breaking various parts of our fragile build system, but I surely want to put something like this on the TODO list for *after* the import has completed. The branch is making progress right now, and I would not want to complicate matters further by introducing yet another tricky feature. :) The build system isn’t so much the issue, but you wind up with files that refer to all the architectures. But this is a request for a new feature, not quite in scope for a compiler upgrade. - Could a MK_CLANG_ALL_TARGETS or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a cross-compile toolchain every iteration for our target MACHINE/MACHINE_ARCH? I would be fine with something like this, as long as it is turned off by default, or if it is only used for the bootstrap stages. It is actually an extremely useful feature of clang that you can target multiple architectures with one compiler binary. This is a new feature. Various people have tried in the past to implement it and compiling just the mips files on mips is straight forward. However, convincing clang to not reference the other architectures requires more sophistication than we currently have in the clang build process. A more interesting case would be to remodel the build system so it can use one toolchain (external, or pkg-ng'd, maybe?) for building an entire universe. With clang, that should be relatively easy to do. Another useful new feature. The hard part with this is getting all the fiddly bits in the tree that depend on default CC producing proper binaries to cooperate.. Doable, but that’s a lot of universe builds. And today it isn’t very practical because sparc64 and mips are broken... Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: RFT: Please help testing the llvm/clang 3.5.0 import
On Dec 18, 2014, at 7:44 AM, Dimitry Andric d...@freebsd.org wrote: On 18 Dec 2014, at 14:34, Robert Huff wrote: Dimitry Andric writes: - Could a MK_CLANG_ALL_TARGETS or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a cross-compile toolchain every iteration for our target MACHINE/MACHINE_ARCH? I would be fine with something like this, as long as it is turned off by default, or if it is only used for the bootstrap stages. It is actually an extremely useful feature of clang that you can target multiple architectures with one compiler binary. Point of information: this seems useful for developers, and (almost entirely) useless for everyone else. Are there other cohorts that want this badly? If that's correct, and there's a simple switch for configuration ... why should this default to what's useful for the (much?) smaller number of people? About what am I ignorant? It's not a simple switch, at least not now. If you use the upstream build system for llvm, e.g. autoconf or CMake, it has an option to select all the architectures that are supported. Several config files are then generated differently, and parts of the target support subdirectories are selectively enabled or disabled. In fact, we already build just a subset of the available architectures, since FreeBSD only supports about 5 of them. We can probably arrange for a more minimal configuration in our build system, but since the build time saved is quite small, I don't think it makes much sense in complicating our build system even further. If people are really so interested in shaving off a little, for more complication, that is fine with me. But unfortunately, I have too many tasks on my plate right now, and I cannot work on it. Besides, doing such a new feature now would interfere with the current branch work. With the recent parallelism work, the is true. It might save a couple percent off the build time. Before those changes, though, disabling all non target arches saved about 10% of the buildworld time. Creating a hack to do this is easy (which is how I measured it). But Dimitry is right that creating a robust solution is hard. Even harder if you want it to be completely clean. Also, after the 3.5.0 import, there are much more interesting fish to fry, in my opinion. For example, importing newer versions of libc++ and compiler-rt, which can bring address sanitizer support, etc. I tend to agree. IMHO, supporting the work going on to bring the meta-mode stuff will pay far higher dividends than optimizing this corner of the build. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Call for testing: elftoolchain tools
We have a rather outdated version of binutils in the base system. As part of a project to update our toolchain I've started working on using some of the tools from the elftoolchain project. There is now a build knob to enable the use of the following tools: * addr2line * elfcopy (strip) * nm * size * strings The knob (in /etc/src.conf) is: WITH_ELFTOOLCHAIN_TOOLS=yes The binutils version is still used for as, ld, objcopy, objdump and readelf; future projects will handle these. The option is being tested in ports exp-runs on amd64 and i386, and has had basic sanity testing on arm64 and mips64. I'm interested in test reports across a variety of hardware architectures and use cases. If everything works as expected you should see no difference -- the tools should be drop-in replacements. -Ed ___ 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: Call for testing: elftoolchain tools
On 12/18/14 10:12, Ed Maste wrote: We have a rather outdated version of binutils in the base system. As part of a project to update our toolchain I've started working on using some of the tools from the elftoolchain project. There is now a build knob to enable the use of the following tools: * addr2line * elfcopy (strip) * nm * size * strings The knob (in /etc/src.conf) is: WITH_ELFTOOLCHAIN_TOOLS=yes The binutils version is still used for as, ld, objcopy, objdump and readelf; future projects will handle these. The option is being tested in ports exp-runs on amd64 and i386, and has had basic sanity testing on arm64 and mips64. I'm interested in test reports across a variety of hardware architectures and use cases. If everything works as expected you should see no difference -- the tools should be drop-in replacements. -Ed ___ 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 I was running WITH_ELFTOOLCHAIN_TOOLS for a few days on head/amd64 and clang350-import/amd64. Things build and work as before. I'm not seeing any behavior differences. - Nikolai Lifanov ___ 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: Call for testing: elftoolchain tools
FWIW, A nice testing procedure, or even a pet project if generalized, would be to test the tools with a fuzzer like security/afl. Apparently the GNU binutils and Fedora elfutils developers having doing that [1]. Regards, Pedro. [1] https://lists.fedorahosted.org/pipermail/elfutils-devel/2014-December/004346.html ___ 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: RFT: Please help testing the llvm/clang 3.5.0 import
On 18 Dec 2014, at 15:47, Warner Losh i...@bsdimp.com wrote: ... * Mips will only have a chance with the upcoming clang 3.6.0, but that is way too late for this import. It will probably require external toolchain support to get it working. For native builds yes. For cross builds, clang 3.6 can be built on an x86 host. Yes, and it could even be one of the ports, if that is easier to use. * Another ports exp-run was done [3], after fixing the problem with lang/gcc, which lead to many skipped dependent ports. * The second exp-run had much better results: the failure with the highest number of dependencies is devel/mingw32-gcc, but this seems to be due to a problem with makeinfo, not clang. The next highest on the list is java/openjdk6, for which ports r374780 [4] was very recently committed. Will users of our stable branch have code similar to the code that caused problems? I'm not sure which code you are referring to here, the openjdk6 code? The code itself is basically fine, but for reasons unknown to me, the port is compiled with -Werror (which is not the case for the other openjdk ports, apparently). Since clang 3.5.0 adds a few new warnings for shaky C++ constructions, these appear during the openjdk6 build, but they are easily suppressed, if upstream does not fix them, or does not care to fix them. I already sent Jung-uk an alternative fix for openjkd6, similar to the one used for www/squid, where warnings are suppressed based on the COMPILER_VERSION variable provided the ports infrastructure. In my opinion it would still be easier to just to turn off -Werror for any third-party code, if we don't feel like modifying it (with all the risks involved). One warning flag about your upgrade to the stable branch would be if there’s a significant number of user-written programs that suddenly become uncompilable with the new clang using the environment that they have today. We know of some items that are issues, so careful attention here is needed. Unless we go proactively looking for these, there’s a good chance we won’t find them until users hit them and start to complain (by which point it is likely too late). Could you post a summary of the issues that ports have hit and the fixes necessary? We may need to have that in the release notes and/or UPDATING file to help prepare our users for the bumps and give them solutions over them. The base system is already completely free of warnings, as far as I know of, so no action is needed there. For ports, the number of failures introduced by new warnings are quite small, as far as I can see, and mostly for ports that are compiled with -Werror. The most encountered new warnings are, off the top of my head: -Wabsolute-value This warns in two cases, for both C and C++: * When the code is trying to take the absolute value of an unsigned quantity, which is effectively a no-op, and almost never what was intended. The code should be fixed, if at all possible. * When the code is trying to take the absolute value, but the called abs() variant is of the wrong type, which may lead to truncation. If the warning is turned off, better make sure any truncation does not lead to unwanted side-effects. -Wtautological-undefined-compare and -Wundefined-bool-conversion These warn when C++ code is trying to compare 'this' against NULL, while 'this' should never be NULL in well-defined C++ code. However, there is some legacy (pre C++11) code out there, which actively abuses this feature, which was less strictly defined in previous C++ versions. Squid does this, and apparently openjdk too. The warning can be turned off for C++98 and earlier, but compiling the code in C++11 mode might result in unexpected behavior, for example the unreachable parts of the program could be optimized away. I would really like to merge this branch to head in about a week, pending portmgr approvall; I don't expect the base system (outside of llvm/clang) to need any further updates. I think there’s good reason to do this, but we should chat about the build issues below before doing it. They are minor, but an important detail. I’ll see if I can find a few minutes to pull the branch and send patches. Lastly, to clear things up about the requirements for this branch (and thus for head, in a while); to build it, you need to have: * A C++11 capable host compiler, e.g. clang = 3.3 or later, or gcc = 4.8 (I'm not 100% sure if gcc 4.7 will work, reports welcome) * A C++11 standard library, e.g. libc++, or libstdc++ from gcc = 4.8. So from any earlier standard 10.x or 11.x installation, you should be good, unless you explicitly disabled clang or libc++. In that case, you must build and install both of those first. This is true only on i386, amd64, and arm hosts. Given that some people do try to do weird things, tightening up how you present this will get the word out a little better. On a 9.x installation, you will have clang by
Re: RFT: Please help testing the llvm/clang 3.5.0 import
On Dec 18, 2014, at 5:02, Dimitry Andric d...@freebsd.org wrote: On 18 Dec 2014, at 02:17, NGie Cooper yaneurab...@gmail.com wrote: On Fri, Nov 28, 2014 at 1:03 PM, Dimitry Andric d...@freebsd.org wrote: ... As a request to speed up the build process further, - Would it be [easily] possible in the clang35 branch to bootstrap the compiler for a specific architecture? The bootstrap / cross compiler for instance always builds N targets instead of building just the desired TARGET/TARGET_ARCH combo. It's not very easy, at least not without breaking various parts of our fragile build system, but I surely want to put something like this on the TODO list for *after* the import has completed. The branch is making progress right now, and I would not want to complicate matters further by introducing yet another tricky feature. :) Fair enough :). - Could a MK_CLANG_ALL_TARGETS or something similar option be added to src.opts.mk to fine tune this process for those of us who don't want to build a cross-compile toolchain every iteration for our target MACHINE/MACHINE_ARCH? I would be fine with something like this, as long as it is turned off by default, or if it is only used for the bootstrap stages. It is actually an extremely useful feature of clang that you can target multiple architectures with one compiler binary. Yes. If make tinderbox could use this it would be useful, otherwise, for most folks it seems like a less interesting feature. A more interesting case would be to remodel the build system so it can use one toolchain (external, or pkg-ng'd, maybe?) for building an entire universe. With clang, that should be relatively easy to do. Agreed. bdrewery is working on something similar to that internally for Isilon. Building the same toolchain N times internally when building the system and your upstream revision of FreeBSD doesn’t change is like testing your sanity — not much changes with the bootstrap compiler/toolchain then! Thanks for the reply :)! signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Call for testing: elftoolchain tools
On 18 December 2014 at 11:53, Pedro Giffuni p...@freebsd.org wrote: test the tools with a fuzzer like security/afl Yes, a very good idea, especially for strings(1) given the way it is often used. I've already found a strings crash with afl. ___ 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: Call for testing: elftoolchain tools
On 2014-12-18 15:02, Ed Maste wrote: On 18 December 2014 at 11:53, Pedro Giffuni p...@freebsd.org wrote: test the tools with a fuzzer like security/afl Yes, a very good idea, especially for strings(1) given the way it is often used. I've already found a strings crash with afl. ___ 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 I cam across this not that long ago: http://lcamtuf.blogspot.ca/2014/10/psa-dont-run-strings-on-untrusted-files.html Our strings didn't crash with his proof of concept, but there may be other similar bugs -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: RFT: Please help testing the llvm/clang 3.5.0 import
On Dec 18, 2014, at 6:51, Warner Losh i...@bsdimp.com wrote: With the recent parallelism work, the is true. It might save a couple percent off the build time. Before those changes, though, disabling all non target arches saved about 10% of the buildworld time. I’m curious. How much is 10% in terms of minutes and with what -j value? Creating a hack to do this is easy (which is how I measured it). But Dimitry is right that creating a robust solution is hard. Even harder if you want it to be completely clean. It didn’t seem incredibly hard — it just required a bit more “generated files” in clang AFAICT. I’ll hang ten until clang35 is in so I can re-asses what’s going on with building it. I tend to agree. IMHO, supporting the work going on to bring the meta-mode stuff will pay far higher dividends than optimizing this corner of the build. True… probably will! signature.asc Description: Message signed with OpenPGP using GPGMail
[PATCH] minstat: default width is terminal width, not 74
The man page states that: '-w widthWidth of ASCII-art plot in characters, default is 74.' This is not entirely correct. The mini-help is more accurate: '-w : width of graph/test output (default 74 or terminal width)' In other words: the man page fails to explain that ministat will default to the terminal width, not 74. It will only fall back to 74 if 'COLUMNS' is not set and ioctl(TIOCGWINSZ) fails. --- usr.bin/ministat/ministat.1 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/usr.bin/ministat/ministat.1 b/usr.bin/ministat/ministat.1 index ea31c23..4550a09 100644 --- a/usr.bin/ministat/ministat.1 +++ b/usr.bin/ministat/ministat.1 @@ -68,7 +68,7 @@ See .Xr strtok 3 for details. .It Fl w Ar width -Width of ASCII-art plot in characters, default is 74. +Width of ASCII-art plot in characters, default is terminal width or 74. .El .Pp A sample output could look like this: -- 2.1.3 ___ 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: RFT: Please help testing the llvm/clang 3.5.0 import
On Dec 18, 2014, at 12:01 PM, Dimitry Andric d...@freebsd.org wrote: On 18 Dec 2014, at 15:47, Warner Losh i...@bsdimp.com wrote: ... * Mips will only have a chance with the upcoming clang 3.6.0, but that is way too late for this import. It will probably require external toolchain support to get it working. For native builds yes. For cross builds, clang 3.6 can be built on an x86 host. Yes, and it could even be one of the ports, if that is easier to use. * Another ports exp-run was done [3], after fixing the problem with lang/gcc, which lead to many skipped dependent ports. * The second exp-run had much better results: the failure with the highest number of dependencies is devel/mingw32-gcc, but this seems to be due to a problem with makeinfo, not clang. The next highest on the list is java/openjdk6, for which ports r374780 [4] was very recently committed. Will users of our stable branch have code similar to the code that caused problems? I'm not sure which code you are referring to here, the openjdk6 code? The code itself is basically fine, but for reasons unknown to me, the port is compiled with -Werror (which is not the case for the other openjdk ports, apparently). Since clang 3.5.0 adds a few new warnings for shaky C++ constructions, these appear during the openjdk6 build, but they are easily suppressed, if upstream does not fix them, or does not care to fix them. I meant “similar code to what’s causing problems” with the build run in their code they build on FreeBSD. If it is a few new warnings for obscure things, we can advice to the release notes about what to avoid and how to mitigate things. I already sent Jung-uk an alternative fix for openjkd6, similar to the one used for www/squid, where warnings are suppressed based on the COMPILER_VERSION variable provided the ports infrastructure. In my opinion it would still be easier to just to turn off -Werror for any third-party code, if we don't feel like modifying it (with all the risks involved). Yea, we can sort out the code in src and ports. I’m more worried about what to tell our users that may be compiling their own code that we don’t control. If these new warnings are ubiquitous, then that could be a problem for adoption (since many shops mandate -Werror as much as possible, and to comply with that mandate would require additional resources when trying to upgrade). If there are a few, then we could just document them and move on. One warning flag about your upgrade to the stable branch would be if there’s a significant number of user-written programs that suddenly become uncompilable with the new clang using the environment that they have today. We know of some items that are issues, so careful attention here is needed. Unless we go proactively looking for these, there’s a good chance we won’t find them until users hit them and start to complain (by which point it is likely too late). Could you post a summary of the issues that ports have hit and the fixes necessary? We may need to have that in the release notes and/or UPDATING file to help prepare our users for the bumps and give them solutions over them. The base system is already completely free of warnings, as far as I know of, so no action is needed there. For ports, the number of failures introduced by new warnings are quite small, as far as I can see, and mostly for ports that are compiled with -Werror. Yea, I wasn’t too worried about this aspect of things. The most encountered new warnings are, off the top of my head: -Wabsolute-value This warns in two cases, for both C and C++: * When the code is trying to take the absolute value of an unsigned quantity, which is effectively a no-op, and almost never what was intended. The code should be fixed, if at all possible. * When the code is trying to take the absolute value, but the called abs() variant is of the wrong type, which may lead to truncation. If the warning is turned off, better make sure any truncation does not lead to unwanted side-effects. -Wtautological-undefined-compare and -Wundefined-bool-conversion These warn when C++ code is trying to compare 'this' against NULL, while 'this' should never be NULL in well-defined C++ code. However, there is some legacy (pre C++11) code out there, which actively abuses this feature, which was less strictly defined in previous C++ versions. Squid does this, and apparently openjdk too. The warning can be turned off for C++98 and earlier, but compiling the code in C++11 mode might result in unexpected behavior, for example the unreachable parts of the program could be optimized away. This is the kind of information I was talking about. Do we have a process to make sure this gets into the release notes? I would really like to merge this branch to head in about a week, pending portmgr approvall; I don't expect the base system (outside of llvm/clang) to need any further updates. I
Re: RFT: Please help testing the llvm/clang 3.5.0 import
On Dec 18, 2014, at 2:17 PM, Garrett Cooper yaneurab...@gmail.com wrote: On Dec 18, 2014, at 6:51, Warner Losh i...@bsdimp.com wrote: With the recent parallelism work, the is true. It might save a couple percent off the build time. Before those changes, though, disabling all non target arches saved about 10% of the buildworld time. I’m curious. How much is 10% in terms of minutes and with what -j value? That depends on how long the build takes. For my 20 minute builds it was about 2 minutes faster. At the time, -j didn’t really effect build times once you got north of 4 because parallelism really sucked. Now it doesn’t suck and it scales much better and I suspect that the time savings would be tiny because it would be done at the same time as other things anyway, but I’ve not measured it directly. Creating a hack to do this is easy (which is how I measured it). But Dimitry is right that creating a robust solution is hard. Even harder if you want it to be completely clean. It didn’t seem incredibly hard — it just required a bit more “generated files” in clang AFAICT. I’ll hang ten until clang35 is in so I can re-asses what’s going on with building it. Yea, and that file generation is a pita, or I’d have committed my changes a while ago... I tend to agree. IMHO, supporting the work going on to bring the meta-mode stuff will pay far higher dividends than optimizing this corner of the build. True… probably will! Yea, this isn’t a problem worth solving today. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: 11-CURRENT r275641 panic: Unrecoverable machine check exception
В Mon, 15 Dec 2014 17:49:54 + Rang, Anton anton.r...@isilon.com пишет: I certainly could be wrong - but how to know for sure the cause of the panic? MCA: CPU 0 UNCOR PCC OVER DCACHE L2 DRD error MCA: Address 0xbd8d4cc0 MCA: Misc 0x30e386 The root cause may be hard to determine, but the immediate cause was helpfully decoded by the kernel. (Though I don't know whether all of the model-specific fields were decoded.) UNCOR = uncorrected error PCC = processor context corrupted (can't safely continue to execute, thus the panic) OVER = error overflow (hmmm, multiple errors occurred) DCACHE L2 DRD = data being read from L2 data cache The miscellaneous register indicates that 0xbd8d4cc0 is a physical address. So this looks like a processor failure. If it is repeatable, though, it may indicate either failed hardware or some problem in configuring the processor (though I'm not sure how that could lead to a cache error). Anton Thank you. ___ 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: RFT: Please help testing the llvm/clang 3.5.0 import
Warner Losh wrote this message on Thu, Dec 18, 2014 at 07:47 -0700: This is excellent news Dimitry! On Dec 16, 2014, at 12:36 PM, Dimitry Andric d...@freebsd.org wrote: On 28 Nov 2014, at 22:03, Dimitry Andric d...@freebsd.org wrote: We're working on updating llvm, clang and lldb to 3.5.0 in head. This is quite a big update again, and any help with testing is appreciated. To try this out, ensure you have good backups or snapshots, then build world and kernel from the projects/clang350-import branch [1]. Please use a Subversion mirror [2], if you are able to. Here are some updates about the status of the 3.5.0 import. * i386 and amd64 have been tested through make universe, and everything should compile and run. * Little-endian ARM builds should now compile and run, thanks to Andrew Turner for putting in lots of work. * Big-endian ARM is apparently supposed to work, but I'm not sure if Andrew managed to test it on real hardware. I know Andrew doesn???t have the right arm gear to do this test, and emulation environments that run FreeBSD have had poor big-endian support for arm. I have a board that I plan to test on shortly... If Andrew would like, I know Jim Thompson has a standing offer to send board(s) to people who will test it... He provided me w/ the board I will be testing on soon... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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: RFT: Please help testing the llvm/clang 3.5.0 import
Dimitry Andric wrote this message on Tue, Dec 16, 2014 at 20:36 +0100: * Big-endian ARM is apparently supposed to work, but I'm not sure if Andrew managed to test it on real hardware. hmmm... I can't get it to compile... Maybe I'm missing something... I tried to do: # make buildworld TARGET_ARCH=armeb WITH_BOOTSTRAP_CLANG= WITH_CLANG= WITHOUT_GCC= WITHOUT_BOOTSTRAP_GCC= This is from an amd64 host, though it is a month or two out of date... But it ended w/: c++ -O -pipe -I/a/src/usr.bin/clang/clang/../../../contrib/llvm/include -I/a/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/a/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver -I. -I/a/src/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\armeb-gnueabi-freebsd11.0\ -DLLVM_HOST_TRIPLE=\armeb-unknown-freebsd11.0\ -DDEFAULT_SYSROOT=\\ -fno-exceptions -fno-rtti -static -o clang cc1_main.o cc1as_main.o driver.o /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontendtool/libclangfrontendtool.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangfrontend/libclangfrontend.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangdriver/libclangdriver.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangserializati on/libclangserialization.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangcodegen/libclangcodegen.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangparse/libclangparse.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangsema/libclangsema.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclanganalysis/libclanganalysis.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangedit/libclangedit.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangast/libclangast.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclangbasic/libclangbasic.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libclanglex/libclanglex.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmoption/libllvmoption.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmlinker/libllvmlinker.a /usr/obj/arm.armeb/a/src/usr.bin /clang/clang/../../../lib/clang/libllvmirreader/libllvmirreader.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmipo/libllvmipo.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmvectorize/libllvmvectorize.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvminstrumentation/libllvminstrumentation.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitwriter/libllvmbitwriter.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmbitreader/libllvmbitreader.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmasmparser/libllvmasmparser.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmdisassembler/libllvmarmdisassembler.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmcodegen/libllvmarmcodegen.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmasmparser/libllvmarmasmparser.a /usr/obj/ar m.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarmdesc/libllvmarmdesc.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarminfo/libllvmarminfo.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmarminstprinter/libllvmarminstprinter.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsdisassembler/libllvmmipsdisassembler.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipscodegen/libllvmmipscodegen.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsasmparser/libllvmmipsasmparser.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsdesc/libllvmmipsdesc.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinfo/libllvmmipsinfo.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmmipsinstprinter/libllvmmipsinstprinter.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmp owerpccodegen/libllvmpowerpccodegen.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcasmparser/libllvmpowerpcasmparser.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcdesc/libllvmpowerpcdesc.a /usr/obj/arm.armeb/a/src/usr.bin/clang/clang/../../../lib/clang/libllvmpowerpcinfo/libllvmpowerpcinfo.a
