Mail Archives: djgpp-workers/2002/03/05/02:47:30
Eli Zaretskii wrote:
>
> On Mon, 4 Mar 2002, CBFalconer wrote:
>
> > > The calls to such hooks could be via function pointers, only if they
> > > are non-NULL. If they are set to NULL by default, the overhead is
> > > just a simple test.
> >
> > It is not necessary IMO. Any such can be done by inserting and
> > calling custom routines, without worrying about interfering with
> > initialization etc.
>
> Features such as those in malldbg.c cannot be implemented that way, since
> they are meant to be used by ordinary users, not source code hackers.
>
> For example, how do you implement a feature that shows a report of
> allocated and free blocks?
See my other posting a few minutes ago. The free blocks can
ALWAYS be traced. From any allocated block all adjacent blocks
can be traced, which is everything EXCEPT if the chains have been
broken by unexpected sbrks. If nothing else in the system is
calling sbrk that won't happen.
If there are orphans left at the end of a run, the trace of the
free blocks will show pointers to at least one of the orphans,
from which the others can be traced.
This is all passive.
Exception: If the remnant of a sbrk has been put in the free list
after an unexpected sbrk, and that remnant has been combined with
all the other allocations from that particular earlier sbrk
sequence via frees, and that total size exactly fits a later
allocation, and was the first in the bucket at the time of that
allocation, it can conceivably be untraceable. The odds are
fairly slim.
--
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)
- Raw text -