Date: Sun, 20 Apr 2003 13:43:18 +0200
From: "Eli Zaretskii" <eliz AT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp-workers AT delorie DOT com
Message-Id: <4634-Sun20Apr2003134317+0300-eliz@elta.co.il>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
In-reply-to: <3EA1C57D.E3861F84@yahoo.com> (message from CBFalconer on Sat, 19
	Apr 2003 17:54:05 -0400)
Subject: Re: nmalloc revisited
References: <10304191903 DOT AA25198 AT clio DOT rice DOT edu> <3EA1C57D DOT E3861F84 AT yahoo DOT com>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Sat, 19 Apr 2003 17:54:05 -0400
> 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.