cil-users — For questions and discussion about CIL.

[CIL users] Adding new features

[Adnan M. <ama...@fi...>]

Hello,

I'm trying to add some new features by modifying the Makefile.in following
the instructions described in the CIL Documentation (
http://cil-project.github.io/cil/doc/html/cil/) section 5.1 (2). The
documentation instructs to "add your module to the CILLY_MODULES or
CILLY_LIBRARY_MODULES variables".
However, I can't find the mentioned variables in the Makefile.in (
https://github.com/cil-project/cil/blob/develop/Makefile.in).

What is the appropriate procedure to add new features?

Thanks,
Adnan

[CIL users] Looking for help maintaining CIL

[Gabriel K. <ga...@ke...>]

Hi,

this list is extremely inactive by now, but some people still submit pull requests for CIL on github.

I have no time anymore to dedicate to CIL unfortunately, but if anybody is interested to help reviewing, testing and merging code requests, I'd be happy to add them as contributors to the Github project.

Just let me know,
-- 
Gabriel Kerneis

[CIL users] No obj subdirectory under CIL

[Kaidi W. <ka...@vt...>]

Hello,
$ ocamlopt -c -I $(CIL)/obj/x86_LINUX/ main.ml
$ ocamlopt -ccopt -L$(CIL)/obj/x86_LINUX/ -o main unix.cmxa str.cmxa \
       $(CIL)/obj/x86_LINUX/cil.cmxa main.cmx
This is the instruction from 1.7.3 document. But I didn’t find obj subdirectory under my cil folder. Can you please let me what I need to do?


Best,
Kaidi

[CIL users] Unbound module Big_int

[Kaidi W. <ka...@vt...>]

Hi,
After I installed CIL and ./configure under cil directory, when I tried to make, I got this error message:


ocamlbuild -build-dir _build -no-links -classic-display src/cil.cma
ocamlc.opt -c -I src -I ocamlutil -I src/frontc -I src/ext -I src/ext/pta -o src/cilint.cmi src/cilint.mli
+ ocamlc.opt -c -I src -I ocamlutil -I src/frontc -I src/ext -I src/ext/pta -o src/cilint.cmi src/cilint.mli
File "src/cilint.mli", line 6, characters 36-51:
Error: Unbound module Big_int
Command exited with code 2.
make: *** [_build/src/cil.cma] Error 10

If I execute “ocaml install num”, it said num has been installed. How can I fix the error? Thank you in advance!

Best,
Kaidi Wang

Department of Computer Science
Virginia Tech

[CIL users] Loop coalescing

[Alex S. <ale...@gm...>]

  Hello.
    I am trying to implement loop coalescing (collapsing) of nested loops
as presented in this paper:
https://www.eecs.berkeley.edu/Pubs/TechRpts/1993/6309.html .

    Are you aware of a similar effort on loop coalescing in CIL? It seems
rather simple to implement, but thought to check with the community.

  Thank you,
    Alex

[CIL users] Boolean expressions are changed

[xueguang <wu...@in...>]

Hi everyone, I find that after using *Frontc.parse_with_cabs *to parse 
the file to Cil.file, some  boolean expressions are changed to an 
assignment to a temporary variable.

E.g.,/assert(x>y).../ is changed to /int tmp=x>y; assert(tmp)...

/Is there any options to turn off this changing ?

Thanks a lot!

Best Regards,
Xueguang

Re: [CIL users] cilly merge file problem

[liaoyuehua <nol...@gm...>]

Thanks for replying back.

I upgrade my CentOS distribution from 6.5 to 6.6,then get installed
recent OCaml and CIL version.Now CIL works well.

Thanks a lot.

Liao.


2015-11-05 6:41 GMT+08:00 Gabriel Kerneis <ga...@ke...>:

> Le 2015-11-02 13:40, liaoyuehua a écrit :
> > /usr/local/bin/cilly.native --out ./demo.cil.c --verbose ./demo.o
> > ./foo.o --mergedout ./demo_comb.c
>
> Cilly hanging reminds me of a bug involving Obj.magic.
>
> > but it could not stop while doing last command until I type
> > ctrl+c.also there is no demo_comb.c created.
> >
> > I use CIL version 1.7.3 on CentOS release 6.5x64 (Final),and Ocamls
> > version is 3.11.2-2.el6.x86_64.
>
> I didn't think it would trigger with 3.11 though. In any case, could
> you please try to get the latest version from git instead and see if you
> can reproduce the issue?
>
> https://github.com/cil-project/cil/
>
> (Also, if at all possible, upgrade your OCaml installation. 3.11 is
> really old. If you are stuck with an old Linux distribution, you could
> still get a recent version using https://opam.ocaml.org/).
>
> Best,
> --
> Gabriel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> CIL-users mailing list
> CIL...@li...
> https://lists.sourceforge.net/lists/listinfo/cil-users
>

Re: [CIL users] cilly merge file problem

[Gabriel K. <ga...@ke...>]

Le 2015-11-02 13:40, liaoyuehua a écrit :
> /usr/local/bin/cilly.native --out ./demo.cil.c --verbose ./demo.o
> ./foo.o --mergedout ./demo_comb.c

Cilly hanging reminds me of a bug involving Obj.magic.

> but it could not stop while doing last command until I type
> ctrl+c.also there is no demo_comb.c created.
>
> I use CIL version 1.7.3 on CentOS release 6.5x64 (Final),and Ocamls
> version is 3.11.2-2.el6.x86_64.

I didn't think it would trigger with 3.11 though. In any case, could 
you please try to get the latest version from git instead and see if you 
can reproduce the issue?

https://github.com/cil-project/cil/

(Also, if at all possible, upgrade your OCaml installation. 3.11 is 
really old. If you are stuck with an old Linux distribution, you could 
still get a recent version using https://opam.ocaml.org/).

Best,
-- 
Gabriel

[CIL users] cilly merge file problem

[liaoyuehua <nol...@gm...>]

Hello

I am trying to merge files(demo.c and foo.c) into one, so I just type
the following commands in the shell.

$cilly --verbose --save-temps --merge --keepmerged demo.c foo.c -o demo

cilly output like that:

Preprocessing demo.c
gcc -D_GNUCC -E -DCIL=1 demo.c -o ./demo.i
Saving source ./demo.i into ./demo.o
Preprocessing foo.c
gcc -D_GNUCC -E -DCIL=1 foo.c -o ./foo.i
Saving source ./foo.i into ./foo.o
Merging saved sources into demo_comb.o (in process of linking demo)
Will merge the following: App::Cilly::KeptFile=HASH(0x143a508)
App::Cilly::KeptFile=HASH(0x143c330)
Will just link the genuine object files:
After merge compile flags:
/usr/local/bin/cilly.native --out ./demo.cil.c --verbose ./demo.o
./foo.o --mergedout ./demo_comb.c


but it could not stop while doing last command until I type
ctrl+c.also there is no demo_comb.c created.

I use CIL version 1.7.3 on CentOS release 6.5x64 (Final),and Ocaml's
version is 3.11.2-2.el6.x86_64.


Thanks.

Liao.

[CIL users] Configuring CIL to compile for 64 bit targets on a 32 bit machine

[Prankur C. <pra...@gm...>]

Hello,

I have started using CIL a week back and compiled 8139too driver for
instrumentation.

The CIL code fails a check IS_ERR( const void * ptr) where it finally checks

(x <http://lxr.free-electrons.com/ident?v=3.14;i=x>) >= (unsigned
long)-MAX_ERRNO
<http://lxr.free-electrons.com/ident?v=3.14;i=MAX_ERRNO>

MAX_ERRNO =4095 and x is typecasted (unsigned long)ptr

I did a printk to get the values of typecasted ptr and MAXERRNO

to my surprise I am getting 64 bit integer value for ptr but 32 bit
value for MAXERRNO

I think this is due to the configuration of the CIL (it might be
configured to compile for 32 bit machines)

since I am running a 32 bit machine (and want to compile the code for
64 bit target)

So now my question is how can i configure to build CIL for 64 bit targets.

There is also a --envmachine option that I can change ( which takes
values from CIL_MACHINE)

but again I dont know how to use that to build for 64 bit targets.

Any help is greatly appreciated :)

Re: [CIL users] Parsing coreutils

[ThanhVu (V. N. <ngu...@gm...>]

I am wondering if this code H.add h "_Static_assert" (voidType, [ TInt
(IBool, []); charConstPtrType ], false);  will match

_Static_assert ((*sizeof* (backup_args) / *sizeof* *(backup_args)) == (
*sizeof* (backup_types) / *sizeof* *(backup_types)) + 1, "verify ("
"ARRAY_CARDINALITY
(backup_args) == ARRAY_CARDINALITY (backup_types) + 1" ")");

because after adding that code to Cil.c ,   Cill still won't recognize
_Static_assert.   The only place where I can find a reference to
_Static_assert is in /usr/include/assert.h , but it 's not enough for me to
determine its parameters.

Vu

On Tue, Oct 6, 2015 at 3:44 PM, ThanhVu (Vu) Nguyen <
ngu...@gm...> wrote:

> I've added this line right above
>
> H.add h "__builtin___fprintf_chk" (intType, [ voidPtrType; intType;
> charConstPtrType ], true) (* first argument is really FILE*, not void*, but
> we don't want to build in th ...
>
> Then recompile cil,  then recompile coreutils but still got the same error
> at the same location.
>
> Vu
>
> On Tue, Oct 6, 2015 at 3:09 PM, Gabriel Kerneis <ga...@ke...>
> wrote:
>
>> Le 2015-10-06 20:55, ThanhVu (Vu) Nguyen a écrit :
>>
>>> _Static_assert ((SIZEOF (backup_args) / SIZEOF *(backup_args)) ==
>>> (SIZEOF (backup_types) / SIZEOF *(backup_types)) + 1, "verify ("
>>> "ARRAY_CARDINALITY (backup_args) == ARRAY_CARDINALITY (backup_types) +
>>> 1" ")");
>>>
>>
>> _Static_assert seems to be introduced by C11, which CIL does not support.
>> I'm not really sure how hard it would be to add: from CIL's point of view,
>> it seems to be nothing more than a function taking a bool and a string as
>> parameter, but I might be missing something.
>>
>> You could try editing cil.ml around that line:
>>
>>
>> https://github.com/cil-project/cil/blob/d9d6a08b8017dea996f3f6a4eef07dc017682d6d/src/cil.ml#L2847
>>
>> to add something like:
>>
>> H.add h "_Static_assert" (voidType, [ TInt (IBool, []); charConstPtrType
>> ], false);
>>
>> Best,
>> --
>> Gabriel
>>
>
>

Re: [CIL users] Parsing coreutils

[ThanhVu (V. N. <ngu...@gm...>]

I've added this line right above

H.add h "__builtin___fprintf_chk" (intType, [ voidPtrType; intType;
charConstPtrType ], true) (* first argument is really FILE*, not void*, but
we don't want to build in th ...

Then recompile cil,  then recompile coreutils but still got the same error
at the same location.

Vu

On Tue, Oct 6, 2015 at 3:09 PM, Gabriel Kerneis <ga...@ke...>
wrote:

> Le 2015-10-06 20:55, ThanhVu (Vu) Nguyen a écrit :
>
>> _Static_assert ((SIZEOF (backup_args) / SIZEOF *(backup_args)) ==
>> (SIZEOF (backup_types) / SIZEOF *(backup_types)) + 1, "verify ("
>> "ARRAY_CARDINALITY (backup_args) == ARRAY_CARDINALITY (backup_types) +
>> 1" ")");
>>
>
> _Static_assert seems to be introduced by C11, which CIL does not support.
> I'm not really sure how hard it would be to add: from CIL's point of view,
> it seems to be nothing more than a function taking a bool and a string as
> parameter, but I might be missing something.
>
> You could try editing cil.ml around that line:
>
>
> https://github.com/cil-project/cil/blob/d9d6a08b8017dea996f3f6a4eef07dc017682d6d/src/cil.ml#L2847
>
> to add something like:
>
> H.add h "_Static_assert" (voidType, [ TInt (IBool, []); charConstPtrType
> ], false);
>
> Best,
> --
> Gabriel
>

Re: [CIL users] Parsing coreutils

[Gabriel K. <ga...@ke...>]

Le 2015-10-06 20:55, ThanhVu (Vu) Nguyen a écrit :
> _Static_assert ((SIZEOF (backup_args) / SIZEOF *(backup_args)) ==
> (SIZEOF (backup_types) / SIZEOF *(backup_types)) + 1, "verify ("
> "ARRAY_CARDINALITY (backup_args) == ARRAY_CARDINALITY (backup_types) 
> +
> 1" ")");

_Static_assert seems to be introduced by C11, which CIL does not 
support. I'm not really sure how hard it would be to add: from CIL's 
point of view, it seems to be nothing more than a function taking a bool 
and a string as parameter, but I might be missing something.

You could try editing cil.ml around that line:

https://github.com/cil-project/cil/blob/d9d6a08b8017dea996f3f6a4eef07dc017682d6d/src/cil.ml#L2847

to add something like:

H.add h "_Static_assert" (voidType, [ TInt (IBool, []); 
charConstPtrType ], false);

Best,
-- 
Gabriel

Re: [CIL users] Parsing coreutils

[ThanhVu (V. N. <ngu...@gm...>]

Hi Grabiel, it expands to

_Static_assert ((*sizeof* (backup_args) / *sizeof* *(backup_args)) == (
*sizeof* (backup_types) / *sizeof* *(backup_types)) + 1, "verify ("
"ARRAY_CARDINALITY
(backup_args) == ARRAY_CARDINALITY (backup_types) + 1" ")");


in the .i file




Vu

On Tue, Oct 6, 2015 at 2:45 PM, Gabriel Kerneis <ga...@ke...>
wrote:

> Le 2015-10-05 22:52, ThanhVu (Vu) Nguyen a écrit :
>
>> /home/tnguyen/Src/Devel/CIL/cil-1.7.3/bin/cilly --merge --save-temps
>> -std=gnu99 -E
>> Line 325 of lib/backupfile.c is
>> ARGMATCH_VERIFY (backup_args, backup_types);
>>
>
> Can you please show us what it expands to in the pre-processed sources?
> Since you already use --save-temps, just lookup the corresponding line in
> the .i file.
>
> Thanks,
> --
> Gabriel
>

[CIL users] Parsing coreutils

[ThanhVu (V. N. <ngu...@gm...>]

Hi, I am trying to parse the coreutils 8.25 using CIL 1.7.3 (on a Debian 8
64 bit machine) but so far has no success.  This is what I've done:


   1. Run ./configure in coreutils-8.23 dir  to create Makefile
   2. Edit the generated Makefile in coreutils-8.23 dir and replace CC,
   CPP, and AR with

   #AR = ar

   AR = /home/tnguyen/Src/Devel/CIL/cil-1.7.3/bin/cilly --merge --mode=AR

   #CC = gcc -std=gnu99
                                                               CC =
   /home/tnguyen/Src/Devel/CIL/cil-1.7.3/bin/cilly --merge --save-temps
   -std=gnu99

   #CPP = gcc -std=gnu99 -E
                                                           CPP =
   /home/tnguyen/Src/Devel/CIL/cil-1.7.3/bin/cilly --merge --save-temps
   -std=gnu99 -E

   3.

   Run make, after a while it will give some error
   ....
   lib/gettext.h:218: Warning: Variable-sized local variable msg_ctxt_id

   lib/gettext.h:264: Warning: Variable-sized local variable msg_ctxt_id

   *lib/backupfile.c[325:16-17] : syntax error*

   Parsing errorFatal error: exception Frontc.ParseError("Parse error")

   Makefile:6634: recipe for target 'lib/libcoreutils.a' failed


   Line 325 of lib/backupfile.c is
   ARGMATCH_VERIFY (backup_args, backup_types);


I then comment out this line (and continue to do so whenever there's a
similar syntax error), but eventually give up because there are just too
many errors like these.  Am I missing something ? I've tried older version
of coreutils 8.19 which was releast several years ago but still have
similar errors.

Thanks,







Vu

Re: [CIL users] deprecated functions vs. oldest supported OCaml version

[Gabriel K. <ga...@ke...>]

Le 2015-09-22 02:17, Ben Liblit a écrit :
> Does commit <https://github.com/c
> il-project/cil/commit/6b3638fc5e79fe82e51fb19d4a909345419225ff> [Fix
> Pretty module for OCaml 4.02], later revised in 
> <https://github.com/cil
> -project/cil/commit/681f17e618282436b8168278af4464036623aaf1> [Safer
> fix for Pretty module] mean that we've already ended OCaml 3.x
> compatibility anyway?  Or were those fixes still OCaml 3.x 
> compatible?

They are 3.x compatible. The old way of doing it (using Obj.magic) 
should never have been used in the first place.

-- 
Gabriel

[CIL users] deprecated functions vs. oldest supported OCaml version

[Ben L. <li...@cs...>]

Compiling the latest CIL code from the "develop" github branch (
https://github.com/cil-project/cil/tree/develop) using OCaml 4.02
produces several warnings about deprecated functions:

     11 warnings about Array.create
      2 warnings about String.copy
     15 warnings about String.set

The Array.create deprecation is fairly old, I think.  But the two
String deprecations only appeared in the 4.x series.  All are easy to
fix, but fixing the String deprecations would presumably mean we could
no longer build CIL using OCaml 3.x.

Are we willing to do that?  What is the *oldest* OCaml release that we
want to be backward-compatible with?  Does commit <https://github.com/c
il-project/cil/commit/6b3638fc5e79fe82e51fb19d4a909345419225ff> [Fix
Pretty module for OCaml 4.02], later revised in <https://github.com/cil
-project/cil/commit/681f17e618282436b8168278af4464036623aaf1> [Safer
fix for Pretty module] mean that we've already ended OCaml 3.x
compatibility anyway?  Or were those fixes still OCaml 3.x compatible?

[CIL users] Is CIL a subset of C?

[Hayden L. <hal...@gm...>]

if so, is there a grammar and type checking information available for CIL?

Re: [CIL users] CIL with SPEC CPU 2006 benchmark

[priyanka <pri...@cs...>]

On 2015-09-08 09:52, priyanka wrote:
> On 2015-09-08 01:54, Gabriel Kerneis wrote:
>> Le 2015-09-07 12:06, priyanka a écrit :
>>> src/lq_complex.h[30:14-22] : syntax error
>>> Parsing errorFatal error: exception Frontc.ParseError("Parse 
>>> error")
>>>
>>> The line mentioned in error contains extern function declaration
>>> whose
>>> return type is #defined. I am quite new to CIL, so can't figure out
>>> exact problem, any pointers would be appreciated.
>>>
>>
>> Can you give the exact content of the line that is failing, after
>> preprocessing? You can use cilly --save-temps to get the
>> pre-processed
>> file.
>
> This is the line:
> extern COMPLEX_FLOAT quantum_conj(COMPLEX_FLOAT a); ---> line 30 from
> lq_complex.h
> where COMPLEX_FLOAT is #defined in another header file as:
> #define COMPLEX_FLOAT float _Complex
>

I have resolved this issue, the COMPLEX_FLOAT is #defined as #define 
COMPLEX_FLOAT float _Complex, but complex.h header file was not 
included. Defining SPEC_CPU_LINUX resolved the problem.

Best Wishes,
Priyanka

Re: [CIL users] CIL with SPEC CPU 2006 benchmark

[priyanka <pri...@cs...>]

On 2015-09-08 01:54, Gabriel Kerneis wrote:
> Le 2015-09-07 12:06, priyanka a écrit :
>> src/lq_complex.h[30:14-22] : syntax error
>> Parsing errorFatal error: exception Frontc.ParseError("Parse error")
>>
>> The line mentioned in error contains extern function declaration
>> whose
>> return type is #defined. I am quite new to CIL, so can't figure out
>> exact problem, any pointers would be appreciated.
>>
>
> Can you give the exact content of the line that is failing, after
> preprocessing? You can use cilly --save-temps to get the 
> pre-processed
> file.

This is the line:
extern COMPLEX_FLOAT quantum_conj(COMPLEX_FLOAT a); ---> line 30 from 
lq_complex.h
where COMPLEX_FLOAT is #defined in another header file as:
#define COMPLEX_FLOAT float _Complex


>
> Thanks,

-- 
Regards,
Priyanka

Re: [CIL users] CIL with SPEC CPU 2006 benchmark

[Gabriel K. <ga...@ke...>]

Le 2015-09-07 12:06, priyanka a écrit :
> src/lq_complex.h[30:14-22] : syntax error
> Parsing errorFatal error: exception Frontc.ParseError("Parse error")
>
> The line mentioned in error contains extern function declaration 
> whose
> return type is #defined. I am quite new to CIL, so can't figure out
> exact problem, any pointers would be appreciated.
>

Can you give the exact content of the line that is failing, after 
preprocessing? You can use cilly --save-temps to get the pre-processed 
file.

Thanks,
-- 
Gabriel

[CIL users] CIL with SPEC CPU 2006 benchmark

[priyanka <pri...@cs...>]

Hi All,

I am trying to process SPEC CPU 2006 benchmark viz.libquantum with CIL, 
but cil.asm gives following error:

src/lq_complex.h[30:14-22] : syntax error
Parsing errorFatal error: exception Frontc.ParseError("Parse error")

The line mentioned in error contains extern function declaration whose 
return type is #defined. I am quite new to CIL, so can't figure out 
exact problem, any pointers would be appreciated.

I am using following command to process benchmark:
/bin/cilly --save-temps=cil-src -I. -DSPEC_CPU -DNDEBUG src/*.c

cil and gcc versions used are cil-1.3.7 and gcc 4.8.4

-- 
Regards,
Priyanka
MTech3, IIT Powai

[CIL users] About the Machine Model and cross compiler

[Rogério P. <rog...@gm...>]

Hello There,

Do I need to specify a Machine Model "--envmachine" when cross compiling?
Isn't the machine information inherited from the cross compiler?

Thank you.

[CIL users] instruction location

[Mauro B. <mb...@gm...>]

Hallo,
I'm trying to log the locations of function calls
However, location.byte gives me the same value for the two calls in
the following line:
return fib(i-1)+fib(i-2);

is this behavior correct/expected? is any other call identifier
available for my purpose?

thanks,
Mauro
-- 
Homme libre, toujours tu chériras la mer!
  - Charles Baudelaire

[CIL users] __attribute__((__visibility__("default"))) ?

[Benjamin Y. <ben...@fa...>]

I noticed some warnings about this visibility attribute when I compiled code produced by Cil. From just a couple minutes of googling and poking around the code, it looks like this has something to do with linking. Cil is applying the attribute to local temp variables that get the return value from library functions (from libuv) that are marked with it.

First, is this an issues anyone else has run into? For now it’s just producing some annoying warnings, but I’d prefer having some clean way to avoid spurious warnings.

Any thoughts on how to deal with this? My first thought is to write a simple visitor that scrubs visibility attributes from local variables.

Thanks,
Ben