From: Hans-Bernhard Broeker Newsgroups: comp.os.msdos.djgpp Subject: Re: Check-Memory Date: 29 Feb 2000 15:22:38 GMT Organization: Aachen University of Technology (RWTH) Lines: 76 Message-ID: <89go7u$i0e$1@nets3.rz.RWTH-Aachen.DE> References: NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de X-Trace: nets3.rz.RWTH-Aachen.DE 951837758 18446 137.226.32.75 (29 Feb 2000 15:22:38 GMT) X-Complaints-To: abuse AT rwth-aachen DOT de NNTP-Posting-Date: 29 Feb 2000 15:22:38 GMT User-Agent: tin/1.4-19991113 ("No Labels") (UNIX) (Linux/2.0.0 (i586)) Originator: broeker@ To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Eli Zaretskii 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.