|
From: Robert W. <rj...@du...> - 2004-11-21 06:45:12
|
About the question of "do we use glibc" versus "do we write our own",
have we looked at any existing alternate libc packages out there?
uClibc, diet libc, klibc, etc. If they're as small as they sound (I
haven't really checked) then there's the possibility of just including
the entire package with Valgrind.
Questions to be answered are:
* What's a comprehensive list of existing libc packages?
* Are they licensed appropriately?
* Do they do everything we want?
* Do they do it in a Valgrind-safe way (brk use, etc.)?
* If not, would they be easy to fix up?
* Are they small enough to include lock, stock and barrel in the
Valgrind source tree?
* If not, is it worth having a separate tree to contain them, with
all of the complications that would add to the build process?
* Are they portable?
* If they're already ported to other OSes and platforms, do they
include ones we care about? (FreeBSD, PPC, x86_64, etc.)
* If not, would they be easy to port?
* How would we deal with integrating new releases, submitting
patches back to the maintainers, etc.?
Lots of questions. I haven't thought about the answers yet.
Assuming I've been smoking the crack pipe and this is a silly idea, how
about making a new vglibc directory (sibling of coregrind) and putting
what's currently found in vg_mylibc.c and vg_pthread* in there,
splitting these n-thousand line files up into something more manageable
and building a libvgc.a?
Regards,
Robert.
--=20
Robert Walsh
Amalgamated Durables, Inc. - "We don't make the things you buy."
Email: rj...@du...
|