aboutsummaryrefslogtreecommitdiff
blob: 6cb777e8709b54666abf96095d448d3381afd216 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
- add support for prof file format so that prof files can be displayed
  at the line-level (this is useful for the uprofile tool under DEC's
  OSF/1)
- take a hard look at --file-ordering (broken) and --function-ordering

+ documentation
+ optimize bfd_find_nearest_line_num() (or replace by different interface)
+ cleanup _bfd_ecoff_find_nearest_line_num() fixes & description
+ ensure "cc -pg" produces good files under OSF/1 v3.0
+ make sure gprof works together with OSF/1 v3.0's profiling libraries
+ implement symtab_parse(); modify sym_lookup() to consider addr_high
+ change gprof.c to collect lists, then invoke symtab_parse() for
  each list
+ Questions:
	o is -c (--static-call-graph) useful at all?  i can't see
	  how; if it were deleted, gprof would be completely machine
	  independent => yup, it is
	o are (long) option names appropriate?
	o -k (--exclude-arc) cannot be implemented with getopt();
	  is new syntax (-k from/to) acceptable?  If not, how to
	  fix it?
	o in the FSF output, the call-graph index now prints
	  the filename of static functions in parentheses; e.g.,
	  static function foo() that is defined in file bar.c
	  would be printed as:

			[4] foo (bar.c)

	  is this acceptable?  should it be done only optionally?
	o symbols with addresses that map back to a different
	  name are suppressed (happens with labels, for example);
	  is this acceptable?  should it be done only optionally?
+ generalize to allow arbitrary histograms (not just time histograms)
+ basic-block information currently replaces all symbols created from
  the core because of an ugly ordering conflict---for now, the current
  solution works, but something cleaner is desirable ==> cleaned up,
  but it's slower now
+ convert to very new file format (back to trivial format, that is :)
+ replace "dummy.h" for Alpha (if there is any use to it)
+ add support for execution time profiling at a basic-block level
+ fix filename-off-by-one bug for Alpha (see ~/tmp/d.[ch])---no longer
  relevant
+ "-pg -a" doesn't work as expected because mcleanup() will overwrite
  the file generated by __bb_exit_func() (or vice versa)
+ first basic-block of fac() seems to get credited to last basic-block
  of previous function => bug in basic_blocks.c
+ flat profile should provide automatic scaling for per-call times because
  otherwise they'll always be zero on a fast machine with tons of small
  functions
+ make "-a" imply to retain line number info (without actually generating
  the debugging information (unless -g is specified)---no, this is a
  bad idea, because it is not clear what level of debugging info should
  be requested (e.g., -g vs. -g3); leaving it up to the user seems best
+ add long options support (or at least use getopt instead of ad-hoc
  implementation)
+ split into files according to abstract objects that are manipulated
+ replace sccsid by rcsid & add "end of ..." to every .c file
+ use DBG() everywhere
+ fix spacing (" ," -> "," etc.)
+ use DEFUNs everywhere
+ make compile cleanly with -Wall
+ "gcc -pg -O2" doesn't work on tecc.c unless -fno-omit-frame-pointer is
  specified; find out why
+ make things portable (prototypes, const, etc.)
+ if NEW_GMON_OUT is not defined, have a flag that will allow to
  read new gmon.out style files.  The idea being that everyone
  will use the new format for basic-block style profiling but
  the old format for regular gpprofiling

Copyright (C) 2012-2019 Free Software Foundation, Inc.

Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved.