Frama-C-discuss mailing list archives

This page gathers the archives of the old Frama-C-discuss archives, that was hosted by Inria's gforge before its demise at the end of 2020. To search for mails newer than September 2020, please visit the page of the new mailing list on Renater.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Frama-c-discuss] Unable to work with large projects

  • Subject: [Frama-c-discuss] Unable to work with large projects
  • From: alexandre.constantino at edisoft.pt (Alexandre Constantino)
  • Date: Fri, 16 Oct 2009 18:23:12 +0100
  • In-reply-to: <1255088687.12374.22.camel@is003138>
  • References: <mailman.93.1255082454.25465.frama-c-discuss@lists.gforge.inria.fr> <1255088687.12374.22.camel@is003138>
Hello,

sorry for the late reply, but only now have I had the time to continue testing frama-c.

After some battles I was able to get it to run on the libdevil project. The idea is interesting, but it becomes very complicated to apply it on an already existing project (eg, something with 1000 .c source files). And even on something you start from scratch, it doesn't seem to be simple to add rules to more complex code. But maybe that's just me who am not used to it.

I was not sure what exactly to expect from frama-c, or any other similar tool, but I wasn't able to make much use of it --- maybe I was unlucky with the project I've chosen as it may have been carefully programmed/checked, since I only got "The name foobar is used for two distinct globals" messages.
I was hopping to use it for dead code removal (but that plugin requires ACSL tags in the code) and also to spot potencial bad programming cases, like race conditions and the likes. Maybe I was hopping for miracles which are just not possible :p

I'm curious about the following, on what type of projects have you run frama-c? Have you tried something like the linux kernel? :)

Minor suggestions:
1) allow the user to provide a filelist.txt of the files to process (this would allow easy integration with the GUI), instead of passing them through a command line variable (or adding each one manually). It would become more practical and I believe there is a limit to the command size you can give to the shell.
2) also support the use of lbt (instead of only ltl2ba), if that is possible: http://www.tcs.hut.fi/Software/maria/tools/lbt/  (the reason is that it's already available at debian/ubuntu repos)


Last but not least: I wasn't able to fully build frama-c:
-----
ocamlopt.opt -I src -I lib -pack -o graph.cmx src/sig.cmi src/sig_pack.cmi src/dot_ast.cmi lib/unionfind.cmx lib/heap.cmx lib/bitv.cmx src/version.cmx src/util.cmx src/blocks.cmx src/persistent.cmx src/imperative.cmx src/delaunay.cmx src/builder.cmx src/classic.cmx src/rand.cmx src/oper.cmx src/path.cmx src/traverse.cmx src/coloring.cmx src/topological.cmx src/components.cmx src/kruskal.cmx src/flow.cmx src/graphviz.cmx src/gml.cmx src/dot_parser.cmx src/dot_lexer.cmx src/dot.cmx src/pack.cmx src/gmap.cmx src/minsep.cmx src/cliquetree.cmx src/mcs_m.cmx src/md.cmx src/strat.cmx
ocamlopt.opt -I src -I lib -a -o graph.cmxa graph.cmx
make[1]: Leaving directory `/home/aconstantino/files/builds/frama-c-Beryllium-20090902/ocamlgraph'
Copying to   lib/graph.cmi
Copying to   lib/graph.cmo
Copying to   lib/graph.cmx
Copying to   lib/graph.o
Copying to   lib/dgraph.cmi
cp: cannot stat `ocamlgraph/dgraph/dgraph.cmi': No such file or directory
-----
I have installed liblablgtk2-gnome-ocaml-dev on my system, but the problem is that that version doesn't has the dgraph.cmi file... nor any other Debian package =(


Thank you.
Best regards,

Alexandre




On Friday 09 October 2009, PUCCETTI Armand wrote:
> Hi Alex,
> 
> (1) yes, this is possible provided you write your own main function
> or take it from some other application that makes use of the library
> (might be a test stub for instance). Make sure that your code is
> relatively complete and watch the log files for messages of the form
> "No code for function...".
> Using -main is obviously preciser than using -lib-entry (see Valviewer
> manual).
> 
> (2) Frama-C does indeed not process entire directories. This would be
> a risky thing as you might also manipulate the source files and/or
> create temporary source files. It is preferable to list precisely 
> all source files that you wish to be analysed. 
> Maybe write a small shell script, with
> 
> SRC = (... source files ...)
> 
> and hand them to the analyser like
> 
> $ frama-c -main <your main> $SRC <other options>
> 
> Armand
> 
> > 
> > ----------------------------------------------------------------------
> > 
> > Message: 1
> > Date: Thu, 8 Oct 2009 17:14:39 +0100
> > From: Alexandre Constantino <alexandre.constantino at edisoft.pt>
> > Subject: [Frama-c-discuss] Unable to work with large projects
> > To: frama-c-discuss at lists.gforge.inria.fr
> > Message-ID: <200910081714.39097.alexandre.constantino at edisoft.pt>
> > Content-Type: Text/Plain;  charset="iso-8859-1"
> > 
> > Hello,
> > 
> > I'm trying to use Frama-C on a large software project, but I'm not having much luck.
> > The problem seems to be twofold: (1) it's a large project with lots of directories and (2) it is a library.
> > 
> > Regarding (2), it's possible to work around this issue by using the -lib-entry flag. But the ideal solution would to set the main() function of an application that uses that library and Frama-C to process the library as well... is this possible?
> > But as for (1), Frama-C seems to work with files, not being able to process directories recursively... and these are way too many URIs (path + filename) to pass in the command line.
> > 
> > Is there any way to solve this?
> > 
> > For example purposes, you can check this library:
> > http://sourceforge.net/projects/openil/files/DevIL/1.7.8/DevIL-1.7.8.tar.gz/download
> > 
> > Thank you for any help.
> > Best regards,
> > Alexandre
> > 
> 
> 
>