new changes in gprof, bfd, gas

new changes in gprof, bfd, gas

[raeburn]

Some of these might be of interest to people:

From David Mosberger-Tang, revised gprof support.  Now alpha-osf
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.  Lots of other changes too; see gprof/NOTES for details.
Texinfo documentation should be forthcoming.

From Bryan Ford, some 16-bit assembly and msdos .exe executable file
support for the i386.  Bryan says he's managed to build a working
memory extender for DOS using this code.  And he even gave me
documentation changes.  Currently the .exe support uses a.out for
object files.

Both these changes should be in tonight's snapshot.

Re: new changes in gprof, bfd, gas

[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.

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).

Jeff

Re: new changes in gprof, bfd, gas

[raeburn]

   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.

Re: new changes in gprof, bfd, gas

[Jeffrey A Law]

  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

Re: new changes in gprof, bfd, gas

[Jeffrey A Law]

  In message < 199502072243.RAA18929@kr-pc.cygnus.com > you write:
  > 
  > Some of these might be of interest to people:
  > 
  > >From David Mosberger-Tang, revised gprof support.  Now alpha-osf
  > 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.  Lots of other changes too; see gprof/NOTES for details.
I notice some problems with the new code:

core_init looks for sections by name.  That is *very* bad for
formats such as SOM & ELF.

The specific problem I see is it looks for $CODE$; well, in
SOM there may be hundreds of $CODE$ sections in a file, and
even if you get all of them you're still going to miss
other sections with code in them like $MILLICODE$.

[ Of course the old code had the same behavior in that it just
  looked for .text; but we never made use of the info for
  SOM/HPUX.  From my quick reading the new code actually wants
  to use information it gathers about sections & their contents. ]

Can someone run this mess through indent?  GNU has formatting
standards, we might as well try to adhere to them.


Jeff

Re: new changes in gprof, bfd, gas

[Richard Stallman]

I am not sure what SOM is, but supporting it is not high priority for
the GNU project.  I have no objection to it if someone feels like
working on it, as long as people understand this work is not
particularly helpful for GNU.

Re: new changes in gprof, bfd, gas

[Jeffrey A Law]

  In message < 199502080056.TAA13633@pogo.gnu.ai.mit.edu > you write:
  > I am not sure what SOM is, but supporting it is not high priority for
  > the GNU project.  I have no objection to it if someone feels like
  > working on it, as long as people understand this work is not
  > particularly helpful for GNU.
ELF has many of the same problems (sans native HP C debug support).

ELF (last I heard) was very important to the GNU project.

Jeff

Re: new changes in gprof, bfd, gas

[Richard Stallman]

    ELF (last I heard) was very important to the GNU project.

Yes, it is.  Wht the sarcasm?  I was talking about SOM, not ELF.

Re: new changes in gprof, bfd, gas

[Jeffrey A Law]

  In message < 199502080434.XAA14004@pogo.gnu.ai.mit.edu > you write:
  >     ELF (last I heard) was very important to the GNU project.
  > 
  > Yes, it is.  Wht the sarcasm?  I was talking about SOM, not ELF.
No sarcasm.

The issues exist for ELF too, which you've confirmed is important for
GNU.  Therefore, we need to keep those issues in mind and try to handle
them correctly.

Jeff

Re: new changes in gprof, bfd, gas

[David Mosberger-Tang]

>>>>> 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