OpenCores
URL https://opencores.org/ocsvn/openrisc/openrisc/trunk

Subversion Repositories openrisc

[/] [openrisc/] [trunk/] [gnu-old/] [binutils-2.18.50/] [gprof/] [TODO] - Blame information for rev 853

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
1 38 julius
 
2
- add support for prof file format so that prof files can be displayed
3
  at the line-level (this is useful for the uprofile tool under DEC's
4
  OSF/1)
5
- take a hard look at --file-ordering (broken) and --function-ordering
6
 
7
+ documentation
8
+ optimize bfd_find_nearest_line_num() (or replace by different interface)
9
+ cleanup _bfd_ecoff_find_nearest_line_num() fixes & description
10
+ ensure "cc -pg" produces good files under OSF/1 v3.0
11
+ make sure gprof works together with OSF/1 v3.0's profiling libraries
12
+ implement symtab_parse(); modify sym_lookup() to consider addr_high
13
+ change gprof.c to collect lists, then invoke symtab_parse() for
14
  each list
15
+ Questions:
16
        o is -c (--static-call-graph) useful at all?  i can't see
17
          how; if it were deleted, gprof would be completely machine
18
          independent => yup, it is
19
        o are (long) option names appropriate?
20
        o -k (--exclude-arc) cannot be implemented with getopt();
21
          is new syntax (-k from/to) acceptable?  If not, how to
22
          fix it?
23
        o in the FSF output, the call-graph index now prints
24
          the filename of static functions in parentheses; e.g.,
25
          static function foo() that is defined in file bar.c
26
          would be printed as:
27
 
28
                        [4] foo (bar.c)
29
 
30
          is this acceptable?  should it be done only optionally?
31
        o symbols with addresses that map back to a different
32
          name are suppressed (happens with labels, for example);
33
          is this acceptable?  should it be done only optionally?
34
+ generalize to allow arbitrary histograms (not just time histograms)
35
+ basic-block information currently replaces all symbols created from
36
  the core because of an ugly ordering conflict---for now, the current
37
  solution works, but something cleaner is desirable ==> cleaned up,
38
  but it's slower now
39
+ convert to very new file format (back to trivial format, that is :)
40
+ replace "dummy.h" for Alpha (if there is any use to it)
41
+ add support for execution time profiling at a basic-block level
42
+ fix filename-off-by-one bug for Alpha (see ~/tmp/d.[ch])---no longer
43
  relevant
44
+ "-pg -a" doesn't work as expected because mcleanup() will overwrite
45
  the file generated by __bb_exit_func() (or vice versa)
46
+ first basic-block of fac() seems to get credited to last basic-block
47
  of previous function => bug in basic_blocks.c
48
+ flat profile should provide automatic scaling for per-call times because
49
  otherwise they'll always be zero on a fast machine with tons of small
50
  functions
51
+ make "-a" imply to retain line number info (without actually generating
52
  the debugging information (unless -g is specified)---no, this is a
53
  bad idea, because it is not clear what level of debugging info should
54
  be requested (e.g., -g vs. -g3); leaving it up to the user seems best
55
+ add long options support (or at least use getopt instead of ad-hoc
56
  implementation)
57
+ split into files according to abstract objects that are manipulated
58
+ replace sccsid by rcsid & add "end of ..." to every .c file
59
+ use DBG() everywhere
60
+ fix spacing (" ," -> "," etc.)
61
+ use DEFUNs everywhere
62
+ make compile cleanly with -Wall
63
+ "gcc -pg -O2" doesn't work on tecc.c unless -fno-omit-frame-pointer is
64
  specified; find out why
65
+ make things portable (prototypes, const, etc.)
66
+ if NEW_GMON_OUT is not defined, have a flag that will allow to
67
  read new gmon.out style files.  The idea being that everyone
68
  will use the new format for basic-block style profiling but
69
  the old format for regular gpprofiling

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.