|
From: Julian S. <js...@ac...> - 2005-03-31 10:32:47
|
This strikes me as a bit like the kernel-headers issue. Although 1 and
2 are attractive from the amount-of-work point of view, the only sane way
to decouple ourselves from the assumptions/difficulties of pre-supplied
kernel headers on random distros Mutant-Linux (etc) was to ship our own.
And so it will be here. Using glibc brings two problems:
* We then have to figure out all the bad ways glibc and valgrind
can interact, be sure we've discovered them all, implement workarounds
for them all, ensure those workarounds don't give rise to more
such problems, and ensure those workarounds don't mess up
maintainability too much.
* What happens on platforms where there is no glibc? MacOSX
and the BSDs? Solaris?
> 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.
It's worth distinguishing between "uses an external header" and
"uses glibc-supplied functions". The first is not such a big
deal (eg, #include <elf.h>). The second is more of a problem.
I had a go at enumerating what we are using in the files Nick
mentioned. Nick, are you sure you found all files using libc
stuff? Anyway:
vg_skiplist: random -- trivially replaced
vg_pthreadmodel: pthread.h, for pthread types
-- seems unavoidable if we want to do pthread modelling
x86/state.c: ptrace, in ptrace_setregs_from_tst
-- not sure what this is for; it does not look to me like
"primary functionality" though
x86-linux/core_platform.h: setjmp.h (setjmp, longjmp, jmp_buf)
-- we need a setjmp/longjmp facility. 1.0.X used GCC's
__builtin_setjmp/__builtin_longjmp to avoid this
dependency; am surprised it is back.
vg_symtab2.c: elf.h, for ELF types/structs/consts, no fns
-- seems fairly harmless, conceivably we could copy the headers
if need be
vg_stabs.c: a.out.h, for stabs types/structs/consts, no fns
-- ditto
stage1.c: not sure this is a problem
-- stage1 can use what it likes since stage2 completely
gets rid of it at startup.
vg_ume.c:
fprintf exit open perror read close sscanf strchr malloc
assert pread strerror memcmp memset free mmap strdup printf
geteuid getegid getgroups stderr errno
These all look like stuff we either do supply ourselves or
could easily do
vg_main.c:
fork ptrace kill fprintf mmap munmap snprintf fstat malloc
read close getenv printf strlen memcmp free access strdup strchr
opendir strerror readdir strncmp closedir dlopen dlerror dlsym
dlclose abort
Apart from ptrace (what's that for? is it essential) the
dl* functions are the only worrying ones.
Most of the glibc functions we use, we already have or can easily
supply. The only stuff which is worrying is:
setjmp / longjmp
dlopen/dlsym/dlclose
ptrace, possibly
Assuming ptrace is fairly harmless (wrapper round the syscall) then
the real worriers are dlopen/dlsym/dlclose and possibly setjmp/longjmp.
J
|