Mail Archives: djgpp-workers/2003/04/20/10:35:54
Eli Zaretskii wrote:
> From: CBFalconer <cbfalconer AT yahoo DOT com>
> > >
> > > The current hooks allow a single library for the library code and
> > > no special linkage steps. Unless the proposed way works with the
> > > code in the standard library, I don't think we can use it.
> >
> > AFAIK the present libc doesn't include the hooks, and you have to
> > use a different library.
>
> No, that's not true. The hooks _are_ included in the current CVS
> version of the library, they just have NULL values (as they are
> global variables). As long as they stay NULL, they are effectively
> disabled, since the code does things like this:
>
> if (__libc_whatever_hook)
> __libc_whatever_hook(args...);
>
> Thus, to activate a hook, all the application has to do is to assign
> a non-NULL value to a hook:
>
> __libc_whatever_hook = my_hook;
>
> Unless I misunderstand, what you suggest does not support this. If it
> does, please describe the procedure to go about this.
>
> > As I said before, I don't like having the hooks exposed as common
> > global variables, and would much rather install/remove them with a
> > single function.
>
> I don't mind having an accessor function to activate and deactivate
> each hook, but then this accessor function needs to be documented.
>
> > As distributed in nmalloc.zip, you can do several things to try it
> > all out without disturbing libc:
> >
> > Normal use - do nothing.
> > Try nmalloc - link malloc.o before searching the library
> > This can be replaced by replacing the
> > malloc.o module in the library.
> > Try debuggery - link both malldbg.o and hookmem.o before
> > searching the library. Again, there is no
> > reason those could not be placed in the
> > library proper, except that if all is
> > suitable I will combine them into a
> > single module.
>
> I was talking about the situation where your code is an integral part
> of libc.a, not a separate library. What would be the procedure to
> produce a program with and without the debuggery hooks in that
> situation? I guess I'm still a bit confused about this.
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. In addition there is an
extra function, described in malldbg.h as follows:
/* proposed future mechanism */
enum m_hook_kind {malloc_HK, malloc_fail_HK,
free_HK, free_null_HK,
realloc_HK, realloc_exit_HK};
/* Depending on kind, some params may be meaningless */
typedef void (*m_hookfn)(size_t sz, void *bk);
/* returns previous value of the appropriate function */
m_hookfn set_m_hook(enum m_hook_kind which, m_hookfn newhook);
and these hooks are, at present, completely independant.
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. The above
set_m_hook function etc. is undocumented except for the header.
Incidentally I don't recall ever complaining about documentation.
I think it is a marvellous job. I did say I couldn't find any on
the debug_malloc stuff, and got pointed to it.
If all goes well with this I can rework to remove the loading of
malldbg code unless the application specifically links to it. I
could make it call the new set_m_hook on non-zero debug_level, I
believe. This would also eliminate the extra _malloc etc. names.
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.
To make this safe, as I see it, the directly addressed hooks have
to go. Leaving them will do no operational harm except to
slightly slow down code execution.
I have NOT claimed that is all ready for system inclusion as it
stands, but that it provides the functionality. According to me
there are no bugs, but I have been known to be wrong about that
before. I expect the changes for direct inclusion to be minimal.
I need real live user feedback.
As I said earlier, the semantics of the various debug_levels need
to be thrashed out.
--
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 -