On Wed, Oct 30, 2019 at 3:23 PM Nowack, Martin <[email protected]> wrote:
> Hi Gleb, > > According to double entries, this is a result of the large-file-system > (LFS) support for 32bit linux systems. > (e.g. https://users.suse.com/~aj/linux_lfs.html) > > All the macro magic leads to generating two different functions for open() > in the resulting bitcode files: > ``` > define i32 @open(i8* nonnull, i32, ...) #0 !dbg !43 { … } > define i32 @open64(i32, i8* nonnull, i32, ...) #0 !dbg !112 { … } > ``` > Therefore, there is no collision under linux. > I see, this is a valueable input, thanks! > Best, > Martin > > On 30. Oct 2019, at 10:28, Gleb Popov <[email protected]> wrote: > > > > On Wed, Oct 30, 2019 at 2:20 PM Nowack, Martin <[email protected]> > wrote: > >> Hi Gleb, >> >> There are two major building blocks: >> >> First, the built libc does *not* contain library calls that are >> intercepted by the POSIX layer. >> It’s on my list to eventually change this. Most of the patches in >> klee-uclibc just comment out those functions or redirect internally used >> function calls to wrapper of those functions to the actual function. >> >> Second, libraries are archives with different object files. Every object >> file is loaded as a separate module and there might be dependencies between >> objects (e.g. calls). >> The point of the looping is that starting from your application which you >> would like to test, you load and pull in all required object files >> transitively by linking with their module. >> The final result is much smaller than linking the whole library as a big >> module blob. This makes the start-up phase of KLEE much smaller and has an >> impact on the execution as well. >> > > This became a bit clearer, thanks. > > Can you comment regarding duplicate definition of "open" in > libkleeRuntimePOSIX.bca? > > >> Best, >> Martin >> >> On 30. Oct 2019, at 07:40, Gleb Popov <[email protected]> wrote: >> >> >> >> On Wed, Oct 30, 2019 at 10:37 AM Gleb Popov <[email protected]> wrote: >> >>> >>> >>> On Tue, Oct 29, 2019 at 10:05 PM Cadar, Cristian <[email protected]> >>> wrote: >>> >>>> Hi Gleb, >>>> >>>> We applied various changes to uclibc to make it work with KLEE, so I >>>> think taking a look at those patches would help. I don't recall the >>>> details, but based on a quick search, I think this patch might be >>>> relevant: >>>> >>>> https://github.com/klee/klee-uclibc/commit/7231f48dd8e2f9f15f721a77639d7eeea6efd38f >>>> >>>> This PR from Martin might also be useful: >>>> https://github.com/klee/klee/pull/483 >>>> Look in particular at linkWithMusllibc() >>>> >>>> I would welcome changes to KLEE to make it easier to plug in other libc >>>> implementations. >>>> >>>> Best, >>>> Cristian >>>> >>> >>> Thanks for pointers. However, some debugging brought me to a strange >>> loop in klee::linkModules() function of Module/ModuleUtils.cpp: >>> >>> while (true) { >>> ... >>> bool merged = false; >>> for (auto &module : modules) { >>> ... >>> linkTwoModules(composite.get(), std::move(module), errorMsg)); >>> } >>> ... >>> } >>> >>> If I understand it right, it exits the loop only when there are no >>> undefined symbols left, but I don't see how linking the same set of modules >>> over and over again can help if we actually have some missing symbol. >>> >>> What am I missing there? >>> >> >> Ok, this boiled down to runtime/POSIX/fd_32.c and runtime/POSIX/fd_64.c >> both having "open" definition. This is what causes linking error. I wonder >> why this works on Linux. Any pointers? >> >> >>> >>>> On 26/10/2019 18:50, Gleb Popov wrote: >>>> > Hello. >>>> > >>>> > I'm trying to make KLEE support FreeBSD libc instead of uclibc. When >>>> I >>>> > run KLEE with my libc.bca, I get the following error: >>>> > >>>> > error: Linking globals named 'open': symbol multiply defined! >>>> > >>>> > It turned out that POSIX runtime contains definition of "open" >>>> function, >>>> > as well as FreeBSD libc do. How to handle this properly? >>>> > >>>> > _______________________________________________ >>>> > klee-dev mailing list >>>> > [email protected] >>>> > https://mailman.ic.ac.uk/mailman/listinfo/klee-dev >>>> > >>>> _______________________________________________ >>>> klee-dev mailing list >>>> [email protected] >>>> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev >>>> >>> _______________________________________________ >> klee-dev mailing list >> [email protected] >> https://mailman.ic.ac.uk/mailman/listinfo/klee-dev >> >> >> >
_______________________________________________ klee-dev mailing list [email protected] https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
