new changes in gprof, bfd, gas

raeburn@cygnus.com raeburn@cygnus.com
Tue Feb 7 16:06:00 GMT 1995


   Date: Tue, 07 Feb 95 16:10:10 MST
   From: Jeffrey A Law <law@snake.cs.utah.edu>

     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.




More information about the Gas2 mailing list