Hi,
scan-build is a part of clang, a C language frontend of llvm. (www.llvm.org, clang.llvm.org). scan-build uses the compiler infrastructure to statically analyze the code, for serious and not-so-serious mistakes. llvm, clang and scan-build are still work in progress, and their results should be used with caution. However, they're quite useful at this time.
The attached patches do the following: 20090310-1-paths: The rules changed in this patch originally wanted to write c_start.o into the source tree. That triggered a bug in my other work, and is generally not what we want.
20090310-2-gcc-for-real: Create a variable "GCC", which defaults to the content of CC, but allows the user to provide a gcc to use in this instance, even when normally a different tool is chosen. That helps with scan-build (see next patch), and might help with distcc, ccache etc, too.
20090310-3-scanbuild: Add support for clang's scan-build utility to abuild. scan-build wraps the compiler and runs its own compiler on the same sources to do some static analysis on them. It adds an option "-sb" or "--scan-build" that creates a coreboot-builds/$target-scanbuild directory for every $target, containing the output of scan-build, which is a HTML documentation on its results. Be aware, that scanbuild significantly increases build time: A board that takes 6-7 seconds normally requires 60 seconds with that option enabled on my test system. The patch also moves the stack-protector option down a bit, so it applies to crosscompiled targets, too (which overwrote the compiler settings before)
I'm currently doing a full abuild run on a recent tree, with the above changes, and the resulting coreboot-builds directory is public at http://www.coresystems.de/~patrick/coreboot-builds/. Feel free to look for bugs in your favorite board support, and fix them! :-)
All of them: Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
Regards, Patrick Georgi
And next time, I'll actually add the patches the first time.
Patrick
On Tue, Mar 10, 2009 at 9:08 AM, Patrick Georgi patrick.georgi@coresystems.de wrote:
Hi,
scan-build is a part of clang, a C language frontend of llvm. (www.llvm.org, clang.llvm.org). scan-build uses the compiler infrastructure to statically analyze the code, for serious and not-so-serious mistakes. llvm, clang and scan-build are still work in progress, and their results should be used with caution. However, they're quite useful at this time.
The attached patches do the following: 20090310-1-paths: The rules changed in this patch originally wanted to write c_start.o into the source tree. That triggered a bug in my other work, and is generally not what we want.
20090310-2-gcc-for-real: Create a variable "GCC", which defaults to the content of CC, but allows the user to provide a gcc to use in this instance, even when normally a different tool is chosen. That helps with scan-build (see next patch), and might help with distcc, ccache etc, too.
20090310-3-scanbuild: Add support for clang's scan-build utility to abuild. scan-build wraps the compiler and runs its own compiler on the same sources to do some static analysis on them. It adds an option "-sb" or "--scan-build" that creates a coreboot-builds/$target-scanbuild directory for every $target, containing the output of scan-build, which is a HTML documentation on its results. Be aware, that scanbuild significantly increases build time: A board that takes 6-7 seconds normally requires 60 seconds with that option enabled on my test system. The patch also moves the stack-protector option down a bit, so it applies to crosscompiled targets, too (which overwrote the compiler settings before)
I'm currently doing a full abuild run on a recent tree, with the above changes, and the resulting coreboot-builds directory is public at http://www.coresystems.de/~patrick/coreboot-builds/. Feel free to look for bugs in your favorite board support, and fix them! :-)
It looks like many of the errors are in the util directory (nrv2b, x86emu, etc.)
I was interested how many parser errors there are, but I couldn't look at them. I get permission denied with the following link:
http://www.coresystems.de/~patrick/coreboot-builds/amd_serengeti_cheetah-sca...
Thanks, Myles
Am 10.03.2009 17:21, schrieb Myles Watson:
http://www.coresystems.de/~patrick/coreboot-builds/amd_serengeti_cheetah-sca...
Fixed. I'll re-add permissions later again, so if you have problems with other boards, just try again later. That thing is still building
Patrick
could you set this up or show me how to set this up for v3?
ron
ron minnich schrieb:
could you set this up or show me how to set this up for v3?
I did a run last night, see http://www.coresystems.de/~patrick/scan-build-2009-03-11-1/ The patch at http://www.coresystems.de/~patrick/scanbuild-for-cbv3.diff contains the changes to the cbv3 tree, but it's definitely not suitable for upstream, unlike the v2 patches I posted.
Regards, Patrick
Am 10.03.2009 19:10, schrieb ron minnich:
could you set this up or show me how to set this up for v3?
Attached patch is more suitable for inclusion into the v3 tree. It adds a "support clang" option to kconfig, and only mangles the variables in question when that option is active.
It's Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
Regards, Patrick Georgi
On 11.03.2009 15:43 Uhr, Patrick Georgi wrote:
Am 10.03.2009 19:10, schrieb ron minnich:
could you set this up or show me how to set this up for v3?
Attached patch is more suitable for inclusion into the v3 tree. It adds a "support clang" option to kconfig, and only mangles the variables in question when that option is active.
It's Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
Regards, Patrick Georgi
Looks good to me.
Acked-by: Stefan Reinauer stepan@coresystems.de
Patrick Georgi wrote:
Attached patch is more suitable for inclusion into the v3 tree. It adds a "support clang" option to kconfig, and only mangles the variables in question when that option is active.
I don't like the particular implementation too much.
+++ Kconfig (working copy)
..
+config SCAN_BUILD
..
+++ util/xcompile/xcompile (working copy)
..
+if [ "$1" = "y" ]; then
- scanbuild=true
+fi
+++ Makefile (working copy)
..
-CC := gcc +CC ?= gcc
..
-HOSTCC := gcc +HOSTCC := $(CC)
..
+include $(shell $(src)/util/xcompile/xcompile $(CONFIG_SCAN_BUILD) > $(src)/.xcompile || \
Couldn't this connection between Kconfig and xcompile work better?
I don't like that it's circular: Makefile is needed to create xcompile which is needed to use Makefile..
I didn't express myself very clearly - do you still get my point?
//Peter
Am 11.03.2009 17:27, schrieb Peter Stuge:
Couldn't this connection between Kconfig and xcompile work better?
I don't like that it's circular: Makefile is needed to create xcompile which is needed to use Makefile..
I didn't express myself very clearly - do you still get my point?
And what is new about that? I changed nothing except passing a variable around. So no, I unfortunately don't seem to get your point.
Regards, Patrick
Patrick Georgi wrote:
Couldn't this connection between Kconfig and xcompile work better?
I don't like that it's circular: Makefile is needed to create xcompile which is needed to use Makefile..
I didn't express myself very clearly - do you still get my point?
And what is new about that? I changed nothing except passing a variable around. So no, I unfortunately don't seem to get your point.
Sorry. :)
Ok.
No, the circular thing is not new, I would like that to change too.
But for CONFIG_SCAN_BUILD, the patch passes it as a parameter to xcompile but I would prefer if environment was used for that communication, both because it is more generic and because it makes it more obvious what is going on.
//Peter
Am 11.03.2009 17:53, schrieb Peter Stuge:
No, the circular thing is not new, I would like that to change too.
Different issue for a different patch, I hope :-)
But for CONFIG_SCAN_BUILD, the patch passes it as a parameter to xcompile but I would prefer if environment was used for that communication, both because it is more generic and because it makes it more obvious what is going on.
The attached patch is the same as the first v3 patch, except that it passes the scanbuild variable by variable, instead of by parameter.
Regards, Patrick Georgi
Patrick Georgi wrote:
No, the circular thing is not new, I would like that to change too.
Different issue for a different patch, I hope :-)
Yes. Sorry for mixing them up.
But for CONFIG_SCAN_BUILD, the patch passes it as a parameter to xcompile but I would prefer if environment was used for that communication, both because it is more generic and because it makes it more obvious what is going on.
The attached patch is the same as the first v3 patch, except that it passes the scanbuild variable by variable, instead of by parameter.
I like it! Please commit!
Acked-by: Peter Stuge peter@stuge.se
On 10.03.2009 17:08, Patrick Georgi wrote:
Hi,
scan-build is a part of clang, a C language frontend of llvm. (www.llvm.org, clang.llvm.org). scan-build uses the compiler infrastructure to statically analyze the code, for serious and not-so-serious mistakes. llvm, clang and scan-build are still work in progress, and their results should be used with caution. However, they're quite useful at this time.
The attached patches do the following: 20090310-1-paths: The rules changed in this patch originally wanted to write c_start.o into the source tree. That triggered a bug in my other work, and is generally not what we want.
20090310-2-gcc-for-real: Create a variable "GCC", which defaults to the content of CC, but allows the user to provide a gcc to use in this instance, even when normally a different tool is chosen. That helps with scan-build (see next patch), and might help with distcc, ccache etc, too.
20090310-3-scanbuild: Add support for clang's scan-build utility to abuild. scan-build wraps the compiler and runs its own compiler on the same sources to do some static analysis on them. It adds an option "-sb" or "--scan-build" that creates a coreboot-builds/$target-scanbuild directory for every $target, containing the output of scan-build, which is a HTML documentation on its results. Be aware, that scanbuild significantly increases build time: A board that takes 6-7 seconds normally requires 60 seconds with that option enabled on my test system. The patch also moves the stack-protector option down a bit, so it applies to crosscompiled targets, too (which overwrote the compiler settings before)
I'm currently doing a full abuild run on a recent tree, with the above changes, and the resulting coreboot-builds directory is public at http://www.coresystems.de/~patrick/coreboot-builds/. Feel free to look for bugs in your favorite board support, and fix them! :-)
Thanks for creating the patch and making these builds available!
All of them: Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
AFAICS --scan-build and --nostackprotect can be specified at the same time, interacting badly. Should we name the parameter "scan-build" or "scanbuild"?
If the two points above are resolved, the whole patchset is Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Regards, Carl-Daniel
Am 11.03.2009 11:52, schrieb Carl-Daniel Hailfinger:
All of them: Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
AFAICS --scan-build and --nostackprotect can be specified at the same time, interacting badly.
That's possible. The nostackprotect change happens to enable nostackprotect with crosscompilers (without it, the crosscompiler test overwrites CC)
In the code, first -fno-stack-protector gets added, then it's pushed into the wrapper script (also necessary for "gcc -m32"), as scan-build doesn't like CC="gcc -arguments". That really looks like it's doing the right thing. I tried a build right now, and it seems to work. (but on that system, nostackprotect doesn't fix otherwise broken builds)
Should we name the parameter "scan-build" or "scanbuild"?
I chose scan-build because that's what the tool is called. On the other hand, --nostackprotect strips the "-", too. I honestly have no opinion on that :-)
If the two points above are resolved, the whole patchset is Acked-by: Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net
Thanks. I'll wait a bit for more opinions on the parameter name, but as the short name stays stable, changing the long version later-on shouldn't be too much of a problem.
Regards, Patrick
On 10.03.2009 17:08 Uhr, Patrick Georgi wrote:
Hi,
scan-build is a part of clang, a C language frontend of llvm. (www.llvm.org, clang.llvm.org). scan-build uses the compiler infrastructure to statically analyze the code, for serious and not-so-serious mistakes. llvm, clang and scan-build are still work in progress, and their results should be used with caution. However, they're quite useful at this time.
The attached patches do the following: 20090310-1-paths: The rules changed in this patch originally wanted to write c_start.o into the source tree. That triggered a bug in my other work, and is generally not what we want.
20090310-2-gcc-for-real: Create a variable "GCC", which defaults to the content of CC, but allows the user to provide a gcc to use in this instance, even when normally a different tool is chosen. That helps with scan-build (see next patch), and might help with distcc, ccache etc, too.
20090310-3-scanbuild: Add support for clang's scan-build utility to abuild. scan-build wraps the compiler and runs its own compiler on the same sources to do some static analysis on them. It adds an option "-sb" or "--scan-build" that creates a coreboot-builds/$target-scanbuild directory for every $target, containing the output of scan-build, which is a HTML documentation on its results. Be aware, that scanbuild significantly increases build time: A board that takes 6-7 seconds normally requires 60 seconds with that option enabled on my test system. The patch also moves the stack-protector option down a bit, so it applies to crosscompiled targets, too (which overwrote the compiler settings before)
I'm currently doing a full abuild run on a recent tree, with the above changes, and the resulting coreboot-builds directory is public at http://www.coresystems.de/~patrick/coreboot-builds/. Feel free to look for bugs in your favorite board support, and fix them! :-)
All of them: Signed-off-by: Patrick Georgi patrick.georgi@coresystems.de
All of them: Acked-by: Stefan Reinauer stepan@coresystems.de
and r3994-r3996.
We're getting considerably close to 4000 commits now :-)
-
Carl-Daniel Hailfinger -
Myles Watson -
Patrick Georgi -
Patrick Georgi -
Peter Stuge -
ron minnich -
Stefan Reinauer