Mail Archives: djgpp/2000/03/01/02:57:11
Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote:
> On 28 Feb 2000, Hans-Bernhard Broeker wrote:
>> At least for all libc
>> functions written in assembly, stubs would have to be written. Same
>> might apply to the 'extern inline' and gcc builtin ones, and all those
>> that call OS services that manipulate memory in the program's arena.
> Thanks for the info. But I'm not sure I understand the last part:
> what exactly do you mean by ``manipulate memory in the program's
> arena''? DJGPP programs don't manipulate the arena memory in the
> usual sense (you can't do that under DPMI), but perhaps you mean
> functions that call malloc/free?
Triggered by this thread, I just had another look at Checker to
refresh my memory about its actual working mechanism. Turned it does
not even work on all kinds of Linux, any more (Checker is lacking
behind, since 1998). It doesn't seem to work with glibc-2.1.
What Checker does is that it keeps a huge table, parallel to the
memory owned by the running process. For each single byte of data
space, it records if it currently contains valid, initialized data, or
rubbish, and wether it is accessible or not.
Now, for every library function that takes a pointer, either that
function itself has to be compiled by 'checkergcc' instead of 'gcc' to
arm it with the necessary checks, or you have to write a wrapper
around it. The wrapper has to check all pointer arguments to see if
they point to accessible memory with valid contents in it. If the
function writes through a passed-in pointer, that bit of content has
to be flagged as 'valid', before returning to the caller. Checker
provides a small library of utility functions and macros to do the
checking.
System calls or assembly routines are intractable by checker-gcc, i.e.
at least for those, you definitely have to write stubs. For DJGPP,
the most prominent examples would be the direct DPMI calls. AFAIK,
at least some of them are passed pointers to program memory, which
they either read to, or write from, or both. Such behaviour has
to be described, by stub functions. Let me show the code for the
'fopen' stub, as an example, and comment on it:
FILE *
chkr_stub_fopen (const char *path, const char *mode)
{
FILE *res;
// two calls to check if the strings passed in are valid for reading:
stubs_chkr_check_str (path, CHKR_RO, "path");
stubs_chkr_check_str (mode, CHKR_RO, "mode");
// do the actual call:
res = fopen (path, mode);
// if everything went well, flag the file descriptor returned by this
// as valid:
if (res != NULL)
fd_returned_by_system (fileno (res));
// I'm not exactly sure why it doesn't have to explicitly flag the
// memory of the FILE structure the result points to as valid, here.)
return res;
}
For Checker to be fully usable, in a given program, each and every
function used by it that has any side effect on memory except for its
own local variables has to be 'checkered'. Either by compiling and
linking it with checkergcc, or by providing a stub.
> Btw, is this documented somewhere? I cannot seem to find anything in
> the GCC docs, but I might be missing something (GCC docs need *lots*
> of work in the indexing area, the index is mostly useless).
Docs for Checker are part of the Checker package, itself. GCC only
documents the options added to it to make Checker possible.
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -