|
From: Nicholas N. <nj...@cs...> - 2005-03-31 03:38:52
|
On Wed, 30 Mar 2005, Jeremy Fitzhardinge wrote: >> Attached is a first cut at a kernel abstraction layer. > > I think we should just use the libc API for this, if not the system glibc. > Would uclibc be a good basis (http://www.uclibc.org/)? It would get us out > of the business of maintaining a C library as well. Perhaps we should stop, think about this, and make a decision before proceeding further, since there it's an important issue and there is some disagreement. Currently we use glibc in a number of modules: vg_main.c, ume.c, stage1.c, vg_stabs.c, vg_symtab2.c, $PLATFORM/core_platform.h, $ARCH/state.c, vg_pthreadmodel.c, vg_skiplist.c. The first three in that list use libc a lot, the others are more minor uses (some only for types and constants, I think). And we also have our own libc implementations of lots of functions. And we've got some external library code in Valgrind (the demangler). So we're using an awkward mix. I see three possibilities here. 1. Use glibc externally, as we do a little bit now. Pros: saves us implementation work. Especialy helpful with complex functions like dlopen() and dlsym() Cons: unclear impact on correctness. Eg. what happens if a library function calls malloc()? 2. Copy a libc into Valgrind, eg. uClibc. Pros: as for (1) Cons: lots of extra code, much of it unused 3. Implement our own libc. Pros: eliminates dependency on outside world, great for correctness guarantees Cons: implementation effort, esp. on different platforms. AIUI, Julian favours (3), Jeremy favours either (1) or (2). I'm leaning towards (3). I've undoubtedly oversimplified the issues involved and missed out some important details. Anyone care to add their two cents? I figure it's a good idea to discuss this and come to some sort of conclusion/agreement before too much implementation effort occurs. N |