From mboxrd@z Thu Jan 1 00:00:00 1970 From: raeburn@cygnus.com To: law@cs.utah.edu, gas2@cygnus.com Cc: David Mosberger-Tang Subject: Re: new changes in gprof, bfd, gas Date: Tue, 07 Feb 1995 16:06:00 -0000 Message-id: <9502072356.AA08833@cujo.cygnus.com> References: <6855.792198610@snake.cs.utah.edu> X-SW-Source: 1995/msg00008.html Date: Tue, 07 Feb 95 16:10:10 MST From: Jeffrey A Law In message < 199502072243.RAA18929@kr-pc.cygnus.com > you write: > configurations are supported, and line-level profiling is available. > The latter requires bfd_find_nearest_line; currently at least ELF and > SOM are missing this support, and the SOM code aborts when it is > called. Right. find_nearest_line may never be supported for SOM; the idea of duplicating a goodly portion of dbxread/stabsread AND hpread from GDB is revolting. Hm. Well, I think eventually we should have gprof support the stabs-in-coff and stabs-in-elf configurations; assuming that were already done, would putting the hooks into som.c to call out to that code be hard? For now, how much trouble would it be to support only the HP native format in find_nearest_line? Probably the approach to take would be what David has already done for ecoff -- when line-number info is first requested, process it all once and build up a cache of the line number or procedure info in memory, then scan it efficiently later as needed. The handling of stabs would probably boil down to code to iterate over the stabs and pass them to some routine that updates the cache appropriately. (That's assuming a cache format that's independent of file format. Or maybe a separate cache for stabs-derived info.) I can certainly change the SOM backend not to abort, but it's not going to give any meaningful results though (I certainly hope there's an option to give the traditional gprof results without using find_nearest_line). Yes, I believe that's the default. And I haven't tested it out myself but I'm pretty sure it'll do something reasonable if find_nearest_line simply fails.