X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Mon, 19 Apr 1999 17:21:45 +0200 (MET DST) From: Hans-Bernhard Broeker X-Sender: broeker AT acp3bf To: Eli Zaretskii cc: djgpp workers list Subject: Re: Probblem: Debug info COFF vs. stabs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Mon, 19 Apr 1999, Eli Zaretskii wrote: > On Mon, 19 Apr 1999, Hans-Bernhard Broeker wrote: > > I have some patches at home, some for gcc (the '-a' [...] > I would think that line-level profiling only needs a macro like MARK, and > all the rest is automagic, since gprof doesn't even know the symbols > generated by MARK aren't real functions. Is there something else? gprof itself already supports line-level profiling, without any further support from gcc being needed. This is relatively easy, actually, as the timing data gathered by 'gcc -pg' compiled programs are timed not by function, but by 4-byte range of code: the timer interrupt just reads out the instruction pointer, and increases a 32bit counter associated to a range of 4 code bytes. gprof in line-by-line profiling mode ('gprof -l') then locates the source line(s) each 4byte range came from, using the 'bfd_find_nearest_line()' function to determine the time spent in each source line. The same information in the gmon.out file is used for the usual function-level profiles, by associating each 4 byte range with the function it came from. It's call counts by source lines where you start to need '-a' profiles. Those are actually basic-block counts, but they help giving counts for the individual lines as well, once you've fiddled them into a gprof-style datafile. Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.