From: Hans-Bernhard Broeker <broeker AT acp3bf DOT physik DOT rwth-aachen DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Check-Memory
Date: 28 Feb 2000 18:30:54 GMT
Organization: Aachen University of Technology (RWTH)
Lines: 28
Message-ID: <89eesu$kkr$1@nets3.rz.RWTH-Aachen.DE>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000228172158 DOT 13170E-100000 AT is>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
X-Trace: nets3.rz.RWTH-Aachen.DE 951762654 21147 137.226.32.75 (28 Feb 2000 18:30:54 GMT)
X-Complaints-To: abuse AT rwth-aachen DOT de
NNTP-Posting-Date: 28 Feb 2000 18:30:54 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 <eliz AT is DOT elta DOT co DOT il> wrote:

> On 28 Feb 2000, Hans-Bernhard Broeker wrote:

>> It'd be quite a huge bit of work to get Checker work on DJGPP

> What exactly makes it such a huge job?

Mainly the writing of stubs for lots (not all) of the library
functions needed to fully exploit the powers of it, and prevent it
from giving false alarms.

Just as a hint, Checker currently only works on two types of machine:
x86-Linux and Sparc-Solaris. The comparison of this short list to the
variety of systems GCC itself runs on may tell you something...

> Do I understand correctly that enabling Checker boils down to some switch 
> to the configure script when building GCC?  The GCC docs (perhaps 
> outdated) seem to imply that libc.a needs also to be rebuilt with the 
> appropriate switches.

It's worse than just rebuilding libc.a, I think. 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.
-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.