new changes in gprof, bfd, gas

Jeffrey A Law law@snake.cs.utah.edu
Tue Feb 7 16:17:00 GMT 1995


  In message < 9502072356.AA08833@cujo.cygnus.com > you write:
  > 
  > 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?
Calling out for the embedded stabs to a common library routine to
handle stabs is easy.  Handling HP C native would still be very
problematical.

The SLT (source line table) doesn't have all the information
we're going to need.  We have to walk down the NTT (name and type)
tables to be able to associate a code address with a file and
line number.

It can be done; it's just a pain.

  > 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.
Certainly.  Canonicalize the information, then throw away all
the debug information -- the debug symbols typically are huge
and we only care about a small portion of them.

  > appropriately.  (That's assuming a cache format that's independent of
  > file format.  Or maybe a separate cache for stabs-derived info.)
I'd highly recommend a canonical format.  It certainly makes
handling




More information about the Gas2 mailing list