X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Fri, 25 May 2001 12:53:42 +0200 (MET DST) From: Hans-Bernhard Broeker X-Sender: broeker AT acp3bf To: djgpp-workers AT delorie DOT com Subject: Re: More control for profiling In-Reply-To: <7704-Wed23May2001220209+0300-eliz@is.elta.co.il> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Wed, 23 May 2001, Eli Zaretskii wrote: > The following changes implement a couple of new functions (by mostly > reusing existing code ;-) which let you control profiling > programmatically from within the program being profiled. Sounds like a good idea. Gprof can do a large part of this, if you really know how to use it (static callgraph deduction, limiting the displayed data to a specific part of the call-graph, etc.), but it can be quite cumbersome, to put it mildly. > The interface is modeled on functions which exist on other platforms > (GNU/Linux and FreeBSD at the very least). Could someone please tell > what header should I put the function prototypes, though? I checked on Digital Unix: they have monitor() and friends . But I wouldn't say that's a particularly good place to put them in. SysV Unix (i.e. SCO, now Caldera) seems to have put monitor() into a headerfile . I don't know what else is in there. > One GNU/Linux box has monstartup in sys/gmon.h, but I wonder if this > is standard, and if it makes sense to add a brand new header just for > this? I would say it does. One could argue that these function should/could go into , but I don't like that idea any better than a separate headerfile. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.