GNU bug report logs - #71925
[PATCH 0/2] Add klee-uclibc.

Previous Next

Full log

Message #20 received at 71925 <at> debbugs.gnu.org (full text, mbox):

From: Sören Tempel <soeren <at> soeren-tempel.net>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: julien <at> lepiller.eu, 71925 <at> debbugs.gnu.org
Subject: Re: [PATCH 2/2] gnu: klee: Build with klee-uclibc support.
Date: Sun, 07 Jul 2024 13:24:53 +0200

Hi Liliana,

Thanks a lot for the quick feedback, responses below.

Liliana Marie Prikler <liliana.prikler <at> gmail.com> wrote:
> The leading colon is pointless here, since you're doing an "=" assign.

Good catch! I can fix this in a patch revision.

> More importantly, can we make this a search path?

I don't think so as it's not a colon separated search path, it can only
point to a single directory; hence, I assumed that wrap-program is more
appropriate here.

> Can we use search-input-file for this and dirname our way up?

The input file that we are looking for here is called libc.a, I am not
sure what the benefit of using search-input-file is, but I personally
think something along the lines of `(dirname (search-input-file
%build-inputs "/lib/libc.a"))` is less readable then `#$klee-uclibc` but
I can definitely change this if you want me to :)

> Is this only distributed as an .a file or could we make a .so out of
> it?

This is only distributed as a .a, not as a shared object. In fact, KLEE
also doesn't not link against this library at all and instead converts
it to an LLVM .bca file (shipped in /lib/klee/runtime/klee-uclibc.bca)
during build. This file is then used directly by KLEE's symbolic LLVM
interpreter to execute code utilizing libc functions. Hence, klee-uclibc
is also not a propagated input for the klee package.

Let me know if I should send a revision, would love to get this merged.

Greetings
Sören

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.