10:08 p.m.
Hi All,
To aid completion of valuable Removal of Dead Code (Implementation) work
funded by OpenSFS [1], Intel HPDD developed a tool to help identify
unused functions, structure members, macros, and variables. I'm pleased
that this tool is now available for anyone to pursue code clean-up work
with automated help.
This tool uses the Clang front-end, augmented by a specially written
plugin. A guide to getting stared is available here:
https://wiki.hpdd.intel.com/pages/viewpage.action?pageId=18645101
The plugin code that provides the necessary augmentation to Clang is
available here:
http://git.whamcloud.com/tools/lustre-static-analysis.git
The code is available under GPLv2.
best regards,
Richard
1. http://wiki.opensfs.org/Contract_SFS-DEV-003
--
Richard.Henwood(a)intel.com
Intel High Performance Data Division
midnight
Richard,
Some notes for improvements needed:
The URL under the git clone line on the wiki page needs fixing. It is
specific to you, Richard.
Next, I would like to see this wiki page on the opensfs wiki instead of
(or in addition to) the Intel wiki.
The information about how to build and use lustre-static-analysis should
be added to the lustre-static-analysis code tree.
The _new_ code is GPLv2, but the part(s) taken from clang/llvm are under
the University of Illinois/NCSA Open Source License, which I think is
basically just the BSD.
Why did you choose GPLv2 when the tool you based it on is BSDish?
We need a bit more of documentation of exactly what the two plugins
actually do.
I would like to see lustre-static-analysis given a bit fuller of a build
system. Ideally it would use autotools. At a minimum it would have a
top-level make file.
Next, it seems to me like the method of invoking the tool is a little
strange. I think I would prefer to have a script that behaves like a
compiler (it calls clang for analysis, and then passes the full command
line to gcc for the real compilation). Right now we have a psuedo-make
command.
So I would like the lustre build commands to look like:
$ sh autogen.sh
$ ./configure CC=my_fine_lustre_clang_wrapper
$ make
That just seems a little more obvious to me then the way it is currently
invoked. Granted, I might be missing something.
Chris
On 07/24/2014 01:08 PM, Henwood, Richard wrote:
Hi All,
To aid completion of valuable Removal of Dead Code (Implementation) work
funded by OpenSFS [1], Intel HPDD developed a tool to help identify
unused functions, structure members, macros, and variables. I'm pleased
that this tool is now available for anyone to pursue code clean-up work
with automated help.
This tool uses the Clang front-end, augmented by a specially written
plugin. A guide to getting stared is available here:
https://wiki.hpdd.intel.com/pages/viewpage.action?pageId=18645101
The plugin code that provides the necessary augmentation to Clang is
available here:
http://git.whamcloud.com/tools/lustre-static-analysis.git
The code is available under GPLv2.
best regards,
Richard
1. http://wiki.opensfs.org/Contract_SFS-DEV-003
2:11 a.m.
Thanks for this feedback Chris, my comments in-line.:
On Thu, 2014-07-24 at 15:00 -0700, Christopher J. Morrone wrote:
Richard,
Some notes for improvements needed:
The URL under the git clone line on the wiki page needs fixing. It is
specific to you, Richard.
fixed.
Next, I would like to see this wiki page on the opensfs wiki instead
of
(or in addition to) the Intel wiki.
Sound good to me.
The information about how to build and use lustre-static-analysis
should
be added to the lustre-static-analysis code tree.
Agreed. I personally favor input from users who use the tool to identify
unused code in Lustre to drive this process.
The _new_ code is GPLv2, but the part(s) taken from clang/llvm are under
the University of Illinois/NCSA Open Source License, which I think is
basically just the BSD.
Why did you choose GPLv2 when the tool you based it on is BSDish?
I have considered the mixing of Licenses. We did the work under
contract. The contract specified GPL2 for code. GPL2 and Clang BSD
license are compatible. I sided with the contract.
We need a bit more of documentation of exactly what the two plugins
actually do.
My suggestion here is that we keep the build and usage instructions in a
single readily available format until more feedback arrives. At that
point we can consider a suitable README in the code or similar.
I would like to see lustre-static-analysis given a bit fuller of a
build
system. Ideally it would use autotools. At a minimum it would have a
top-level make file.
As part of Removal of Dead Code, this plugin proved valuable -- but it
must be said that with the conclusion of that project, we cannot commit
to on-going maintenance. The license, of course, allows anyone to
modify, distribute and provide that role.
If there is general interest in this tool, I guess the best place is to
voice that here and at the TWG?
Next, it seems to me like the method of invoking the tool is a little
strange. I think I would prefer to have a script that behaves like a
compiler (it calls clang for analysis, and then passes the full command
line to gcc for the real compilation). Right now we have a psuedo-make
command.
So I would like the lustre build commands to look like:
$ sh autogen.sh
$ ./configure CC=my_fine_lustre_clang_wrapper
$ make
That just seems a little more obvious to me then the way it is currently
invoked. Granted, I might be missing something.
Probably not. Our project goal was to delete unused code from Lustre
[1]. We developed this tool enough to get us to the goal. There is more
unused code, and I think further use of this tool will drive the next
enhancements.
best regards,
Richard
1.
http://wiki.opensfs.org/images/f/f4/RemovalOfDeadCode_ScopeStatement.pdf
--
Richard.Henwood(a)intel.com
Intel High Performance Data Division
2683
days inactive
2684
days old
2 comments
2 participants
participants (2)
-
Christopher J. Morrone -
Henwood, Richard