This is the mail archive of the gas2@sourceware.cygnus.com mailing list for the gas2 project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
>>>>> 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