Hi Brent,
On Wed, Aug 4, 2010 at 11:00 AM, Brent Lim brentlim at brentlim.net wrote:
I have been trying to reproduce the bugs in Coreutils 6.10 mentioned in the
2008 OSDI paper, ?KLEE: Unassisted and Automatic Generation of High-Coverage
Tests?, but have not been successful.
I have looked
Hi Hemanth,
KLEE doesn't support use of dlsym/dlopen. KLEE works best when you
have a closed program, where all the code is compiled in. If you
don't, then for calls like dlsym/dlopen KLEE will just use the native
versions, but it doesn't understand that the result you get back from
dlsym is
Hi Kuan,
It looks like you are using mismatched versions of the LLVM tools. You
probably have an llvm-gcc from a newer LLVM (e.g., 2.7) installed
somewhere in your path.
Make sure when you configure LLVM that it is finding an llvm-gcc which
matches the same version of LLVM.
- Daniel
On Fri,
--
Heechul
-- next part --
A non-text attachment was scrubbed...
Name: openOutputFile.patch
Type: text/x-diff
Size: 594 bytes
Desc: not available
Url :
http://keeda.Stanford.EDU/pipermail/klee-dev/attachments/20100805/f9e32b3b/attachment.bin
Thanks, Cristi, that's a very good idea. I added this and applied the
patch in 110329.
Best,
Cristian
On 05/08/10 10:57, Cristian Zamfir wrote:
Hi Cristi,
Indeed, if we call klee_error instead of klee_warning, there is no point in
calling it from everywhere. I didn't test, but the patch
Hi, it would be indeed useful to set up a bigger regression suite which
would make sure that KLEE still finds the bugs in Coreutils. So it
would be great if anybody would offer to do this.
However, to reproduce the bugs, I would recommend trying the KLEE and
LLVM versions from the time of
Daniel wrote:
Make sure when you configure LLVM that it is finding an llvm-gcc which
matches the same version of LLVM.
This statement would be a good addition to the
http://klee.llvm.org/GetStarted.html
instructions.
Regards,
Michael
