new changes in gprof, bfd, gas

David Mosberger-Tang davidm@cs.arizona.edu
Tue Feb 7 16:22:00 GMT 1995


>>>>> On Tue, 7 Feb 1995 18:56:43 -0500, raeburn@cygnus.com said:

  Ken> Probably the approach to take would be what David has already
  Ken> done for ecoff -- when line-number info is first requested,
  Ken> process it all once and build up a cache of the line number or
  Ken> procedure info in memory, then scan it efficiently later as
  Ken> needed.

As I have mentioned before, for gprof purposes, it would be much more
efficient to have a function walk_line_syms() that takes a callback
function as an argument.  The callback would be invoked once for each
line symbol and would provide the same information as
find_nearest_line() currently does (i.e., address, filename,
functionname, and line-number).  I believe this is also easier to
implement because the symbols can be processed in an order that suits
the object-file format.

Just my 2 cents though...

  Jeff>    I can certainly change the SOM backend not to abort, but
  Jeff> it's not going to give any meaningful results though (I
  Jeff> certainly hope there's an option to give the traditional gprof
  Jeff> results without using find_nearest_line).

  Ken> Yes, I believe that's the default.  And I haven't tested it out
  Ken> myself but I'm pretty sure it'll do something reasonable if
  Ken> find_nearest_line simply fails.

It works fine as long as find_nearest_line() returns false when it
doesn't have debugging info available (either because it's not
implemented or because the image doesn't have debugging info).

	--david




More information about the Gas2 mailing list