X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Message-ID: <3C82961C.ECB957F1@yahoo.com>
Date: Sun, 03 Mar 2002 16:31:08 -0500
From: CBFalconer <cbfalconer AT yahoo DOT com>
Organization: Ched Research
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: Malloc/free DJGPP code
References: <10203021522 DOT AA15526 AT clio DOT rice DOT edu> <3C8118C3 DOT C4EF9685 AT yahoo DOT com> <4331-Sat02Mar2002220420+0200-eliz AT is DOT elta DOT co DOT il> <3C8179B3 DOT F5529DFD AT yahoo DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

CBFalconer wrote:
> 
> Eli Zaretskii wrote:
> >
> > > Date: Sat, 02 Mar 2002 13:24:03 -0500
> > > From: CBFalconer <cbfalconer AT yahoo DOT com>
> > >
> > > No great sweat doing that, but as I discovered early on malloc is
> > > used during initialization and if any errors occur then writing to
> > > stdout at least is fatal and useless.
> >
> > It's fatal if you use buffered stdio functions.  If you use `write'
> > (or even `_write') instead, it's not fatal.  The crash message is
> > written using these methods, and you could do the same with some
> > additional text you print before you abort.
> 
> Already put it in, along with things in the test software to
> trigger it.  It is using write, but it doesn't need sprintf and
> buffers etc. so it does become quite simple.  Seems to be working
> fine, and I am replacing asserts with it now.  Detecting freeing a
> freed block is not as positive as I thought, because it may have
> been combined with other blocks, and the combined block is what is
> marked as free.  However the asserts that are being changed over
> seem to catch that nicely.
> 
> Maybe the output message should tell them to "run symify
> <progname>"?  Really a detail that can be handled at anytime.

Another thought, which applies to any revision of the present
system also.  I am including a system header file to connect any
debuggers.  It looks like this:

/* -------- sysquery.h ------------ */

#ifndef sysquery_h
#define sysquery_h
#ifdef __cplusplus
   extern "C" {
#endif

/* This allows a clean connection to debugging software */
struct _sysquery {
   unsigned char data, gdlo, sz, prvf, nxtf, nxt, prv, ohead;
   void *        nil;
};

/* This can return the above values, hopefully in a register    */
/* NONE is used in nextfree, prevfree as the equivalent of NULL */
/* With the unclean knowledge that nil is actually a pointer to */
/* freehdrs[1], and that lastsbrk is actually freehdrs[0], the  */
/* entire malloc structure is open to debuggery.                */
struct _sysquery _sysmalloc(void);

#ifdef __cplusplus
   }
#endif

#endif
/* -------- sysquery.h ------------ */

This gives sufficient knowledge to build external memory system
debuggers.  I am testing it by moving some of the debugging code
external now.  Incorporating a version into the present system
would provide a smooth path for revision of any debugging code. 
Once the header exists, the debuggers can refer to it, and then
any future changes will be automatically propagated through the
headers. 

I suspect the present debuggers only need the sz and data
offsets.  data and ohead will normally be the same, unless guard
areas are above the data area.

-- 
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT XXXXworldnet DOT att DOT net)
   Available for consulting/temporary embedded and systems.
   (Remove "XXXX" from reply address. yahoo works unmodified)
   mailto:uce AT ftc DOT gov  (for spambots to harvest)