[Top][All Lists]

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

Re: [Liberty-eiffel] producing debug version od compile_to_c

From: Raphael Mack
Subject: Re: [Liberty-eiffel] producing debug version od compile_to_c
Date: Sun, 26 Oct 2014 18:17:12 +0000
User-agent: Internet Messaging Program (IMP) H5 (6.2.1)

Hi Laurie,

the install script compiles the compiler with

compile_to_c -verbose -boost -no_gc compile_to_c -o

So the difference is the garbage collector, which is switched off normally for compile_to_c (and some other tools). And you probably know the current situation, that eiffeldoc fails to generate the html on which is related to a problem in the GC when it seems to free some still referenced (probably in a native array) objects (which likely yields a segfault) .

Debugging the compiler ist quite hard, as the contracts in it are not as good as we'd like them to be and if you check them, it gets so slow, that it is impossible to work with it. Often using "-verbose" when compiling the target application in combination with reading the source compiled before the crash helps to extract the reason for the crash into a small examlpe to reproduce the bug. (a Segfault is always a bug in the compiler, even if the input is also malicous). I'd be interested in this kind of small example code showing the bug, to be able to add it to the test suite.

I hope you still want to go for it, so you might want to look at Liberty/work/debug/checks/c2c.ace which is a starting point to check SOME contracts in the compiler. But with this approach the challenge is to actiavte the interesting contracts and disable all which make the thing slow ;-)

For segfaults it is probably best to debug compile_to_c with gdb (add "-g" to the command line")...


Zitat von Laurie Moye <address@hidden>:


I have a program which crashes compile_to_c when I try to compile it with the adler version.

I have tried to create debug versions of compile_to_c to see if I can find out what's happening, but every version that I create, even a -boost version compiled with:
compile -boost compile_to_c -o compile_to_c-boost
produces a compile_to_c that fails with SIGSEGV even when I try to use it to compile hello_world.

I can see that my compile_to_c produced in this way is of a different length to the one produced by he install process, so I'm obviously doing something wrong.

Is there a standard way of producing debug versions of compile_to_c in order to track down failures?

Best wishes,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]