Hi Cristian! Thanks for partially committing :).

(1) STP - okay, I'll submit my change there and use a separate STP build
directory for my klee package.

(2) KLEE_LIB_DIR specifies the installed directory (safe to always
specify), USE_KLEE_LIB_DIR changes runtime klee behaviour (by default not
set). I.e. I'm separating behaviour from information. So really just an
added hook that does nothing by default, but is needed for package builders
that want to make binary-only packages.

Using a single macro overriding the default isn't easy to do cleanly as the
buildsystem has knowledge of the installed libdir, but the process
performing the building knows which behaviour it wants klee to follow;
neither is in a position to know both and specify them cleanly imho, hence
the suggested separation.

Thanks for your feedback!

Cheers,
Ben

On Sun, Dec 11, 2011 at 11:27 PM, Cristian Cadar <[email protected]>wrote:

> Hi Ben,
>
> Thanks for your patches.  I already pushed a few of your changes here:
> http://llvm.org/viewvc/llvm-**project?view=rev&revision=**146352<http://llvm.org/viewvc/llvm-project?view=rev&revision=146352>
> http://llvm.org/viewvc/llvm-**project?view=rev&revision=**146353<http://llvm.org/viewvc/llvm-project?view=rev&revision=146353>
>
> A few comments about your other changes:
> (1) RUSAGE_SELF: you should send this patch to the STP developers.  I plan
> to slowly move away from our very old version of STP.  This version does
> not compile correctly with some recent versions of gcc, and it's also
> slower than newer versions.  In particular, r940 of STP (recommended on the
> website) seems to be quite stable.
>
> (2) KLEE_LIB_DIR feature: why do you need both KLEE_LIB_DIR and
> USE_KLEE_LIB_DIR?
>
> Thanks,
> Cristian
>
>
> On 12/09/2011 07:02 PM, ben gras wrote:
>
>> Dear all,
>>
>> Attached is a patch I would like to submit for committing. They are
>> changes
>> motivated by compiling and running klee under Minix, w.r.t. the latest SVN
>> HEAD (r146265), which builds and works again thanks to the latest API
>> adjustment, thanks to arrowdodger.
>>
>> They are pretty minor fixes so I hope it's OK to submit them all in one
>> patch. Explanation:
>>
>> . ntohs: takes a uint16_t, and compiler knows about the general prototype;
>> otherwise compiling breaks with the inconsistent declaration.
>> .<unistd.h>  added in 2 files fixes missing prototypes
>> . added a KLEE_LIB_DIR and USE_KLEE_LIB_DIR facility to distinguish
>> searching for klee generated library files in the klee source directory
>> vs.
>> in the installed location; this lets me make a binary-only klee package
>> (together with our compiler, clang/llvm) that can be used standalone by
>> Minix users, without the build directories installed. I have a pkgsrc
>> package for it at
>> http://git.minix3.org/?p=**pkgsrc.git;a=tree;f=minix/**clangnew;h=**
>> f7a88a0c62f8c325c46e3860991bff**731ad9c169;hb=refs/heads/**minix-masterif<http://git.minix3.org/?p=pkgsrc.git;a=tree;f=minix/clangnew;h=f7a88a0c62f8c325c46e3860991bff731ad9c169;hb=refs/heads/minix-masterif>
>> you're interested. This will install klee along with the compiler out
>> of
>> the box under Minix.
>> . no stat64 under Minix
>> . ignore resource limits if RUSAGE_SELF isn't defined, i.e. getrusage()
>> not
>> available
>> . Minix doesn't support mmap()ed files currently, but theMMap seemed to be
>> unused, so I hope it's okay to remove it (cleanest solution if possible).
>>
>> I am looking forward to exploring the possibilities of improving Minix
>> code
>> and test coverage using klee, and this package is a first step. Committing
>> the above would reduce our patch load significantly and will hopefully
>> also
>> facilitate compiling and packaging for other platforms. Thanks for Klee,
>> I'm excited about it!
>>
>>
>>
>>
>> ______________________________**_________________
>> klee-dev mailing list
>> [email protected]
>> http://keeda.Stanford.EDU/**mailman/listinfo/klee-dev<http://keeda.Stanford.EDU/mailman/listinfo/klee-dev>
>>
>


-- 

Regards,
Ben
_______________________________________________
klee-dev mailing list
[email protected]
http://keeda.Stanford.EDU/mailman/listinfo/klee-dev

Reply via email to