0041ebc4bd
git-svn-id: https://swig.svn.sourceforge.net/svnroot/swig/trunk@10001 626c5289-ae23-0410-ae9c-e8d60b6d4f22
78 lines
2.7 KiB
Text
78 lines
2.7 KiB
Text
The WAD Developers Guide
|
|
|
|
David Beazley (beazley@cs.uchicago.edu)
|
|
|
|
$Id$
|
|
|
|
1. Introduction
|
|
|
|
This short document is intended for anyone who feels inclined to work
|
|
on WAD and make improvements. It is by no means complete. However,
|
|
it contains random commentary on the current implementation.
|
|
|
|
2. A brief word on the execution environment
|
|
|
|
Because WAD is embedded in the same application it is intended to
|
|
debug, it must take an extremely conservative approach to its own
|
|
execution environment. Specifically, it can not rely upon the correct
|
|
operation of C library--especially with respect to memory management
|
|
and other basic operations. Because of this, the implementation of
|
|
WAD makes every effort to be as self-contained as possible--thus
|
|
minimizing its exposure to corrupted libraries in the faulting
|
|
application. Closely related to this, WAD does not rely on any
|
|
third-party libraries (e.g., libbfd) since it is almost impossible to
|
|
fully verify the way in which such libraries might use other programming
|
|
libraries.
|
|
|
|
With that said, you might keep the following rules in mind:
|
|
|
|
rule 1: Trust nothing--it might be broken.
|
|
rule 2: When in doubt, see rule 1.
|
|
|
|
(Of course, we can probably get away with assuming that the OS isn't
|
|
hosed).
|
|
|
|
3. Memory management
|
|
|
|
There are two problems here: first, the dynamic memory
|
|
allocator may be corrupted or broken (e.g., as might occur when
|
|
you double-free memory or free memory not allocated by malloc).
|
|
Second, the WAD signal handler prefers to execute own on its own
|
|
signal handling stack. This stack is of limited size so it is not
|
|
a reliable place to put large amounts of data.
|
|
|
|
Small buffers and scratch areas are managed through the use of static
|
|
variables allocated in the WAD data-segment.
|
|
|
|
For dynamic memory management, WAD provides its own memory allocator
|
|
in the function wad_malloc(). This function allocates memory by using
|
|
mmap() to grab anonymous memory regions (mapped to /dev/zero). This
|
|
memory is currently allocated in chunks of 64Kbytes as needed.
|
|
|
|
To simplify the implementation and prevent potential memory problems
|
|
in WAD itself, WAD never releases the memory that it allocates. There
|
|
is no wad_free() operation nor is there any way to release all of the
|
|
memory previously allocated.
|
|
|
|
Although memory is never released, WAD tries to intern commonly used
|
|
strings. An internal string hash is built as WAD runs and in most
|
|
cases, each string is mapped to a single instance of the string in
|
|
this hash table. The function wad_string_lookup(char *s) is used to
|
|
return a pointer to the string s in the hash table. If no entry
|
|
exists, it is created and a pointer is returned.
|
|
|
|
4. I/O
|
|
|
|
It is probably a bad idea to use buffered I/O with WAD. This may
|
|
result in implicit calls to malloc() and related functions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|