Mail Archives: djgpp-workers/2003/04/20/21:36:40
Eli Zaretskii wrote:
>
> > Date: Sun, 20 Apr 2003 10:14:04 -0400
> > From: CBFalconer <cbfalconer AT yahoo DOT com>
> >
> > When I combine it into a single module, it will work exactly as
> > you described it if mounted in the library. The hook pointers
> > will be NULL, and can be set directly.
>
> Then please reiterate why is it necessary to define `malloc', `free',
> etc., which are standard functions, in your version of malldbg.c, and
> have them call `_malloc', `_free', etc. Will this go as well when
> nmalloc is part of the standard library?
In a word, yes.
>
> > To address Charles Sandmanns concern over the documentation, I
> > have implemented it exactly to the existing documentation, with
> > the exception that malloc_debug has an additional FILE* parameter
> > to set the file on which to display results. If that is NULL
> > stderr is used. Easily changed back to eliminate the FILE*, and
> > add a new name or macro for that functionality.
>
> That's okay, but the additional functionality--the ability to control
> where the messages go--needs to be documented.
I agree, but the mechanics of it are not simple for me. The doc
change is only a line or two in the description of malloc_debug.
>
> > If all goes well with this I can rework to remove the loading of
> > malldbg code unless the application specifically links to it.
>
> Please tell the details. Does the user needs to do anything besides
> calling function(s) in malldbg? I'd like to avoid any additional
> requirements.
And include the appropriate header, of course. Malldbg
initializies in level 0, and does nothing. No hooks are set,
etc. To do anything the user has to call something in malldbg.
Here is where the semantics of debug_level come in. It seems
purposeless to prevent some of the dumps without leaving level 0,
but it might be safer for future changes.
>
> > What I envision is that the sysquery.h header will be expanded
> > slightly, so that externals can discover the address of the above
> > set_m_hook and the corresponding enum. The malldbg module will
> > use this to sink its own hooks. The piece of information holding
> > the heads of the "unexpected" sbrk chains will also be moved into
> > malloc proper, and its location exposed through sysquery.h and the
> > _sysmalloc call, thus hidden from prying. Without including
> > sysquery.h the whole system is immune to accidents from valid
> > code. With sysquery.h it is wide open. #including <malldbg.h>
> > allows malldbg.o to be loaded, which calls sysquery etc.
>
> It is not quite clear to me how this will work. Please elaborate, or
> post an example.
I don't see any way of handling the original debug hooks without
publishing them directly from nmalloc, so for my purposes I will
assume they are not published. _sysmalloc now returns a structure
which describes the various offsets within the internal malloc
system. It also returns a pointer to an array of heads to the
free header lists, with the convention that indices 0 and 1 of
that array are special. 0 describes the slopchest, i.e. the
remnant from any sbrk call, and 1 is never to be used, since the
address replaces NULL in some situations where I have to
distinguish from a real NULL. I am going to add a pointer to the
field of unexpected sbrk headers, used to anchor allocation lists,
and a pointer to the internal sethook call, described above. The
users sethook call will go via the malldbg module and use this to
access the real hooks. Maybe he should be forbidden from using it
unless the debug_level is zero, to avoid contention. Similarly, a
malloc_debug level setting call will be refused if any hooks have
been set and the level is zero. There is a need to keep these
things from clashing.
So, after program startup, the user can:
a) call sethooks, and do his own thing. This inhibits any
further setdebuglevel calls until the hooks are removed.
b) call setdebuglevel, and use the facilities provided.
This prohibits calling sethooks until the level returns
to level zero.
meanwhile the malloc module is doing its normal thing, and keeping
all its normal records. That includes linking all the free space,
and linking all blocks in memory order.
(I am bandying the names about, those are inaccurate). Virtually
no code is added to the load module unless malldbg is loaded,
which it won't unless the user has calls to it in his code.
Everything then lives in the standard library, and no linker games
are needed.
This is the end plan, more or less, NOT the way it acts in
nmalloc.zip. But I see a plain path to it, PROVIDED everything is
functional and tested with who knows what. The safety interlocks
are not there now, but should be in the long run, because all
memory is wide open to misuse in DOS and W9x. Sinking a hook to
an arbitrary location is inherently unsafe, but I want to protect
against the basically friendly user and his misunderstandings.
>
> > According to me there are no bugs, but I have been known to be wrong
> > about that before.
>
> Being bug-free is not a requirement for code to be included in the
> library ;-)
>
> > As I said earlier, the semantics of the various debug_levels need
> > to be thrashed out.
>
> Again, let's talk about the details.
Above, in large part.
--
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
- Raw text -