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

Subversion Repositories openrisc

[/] [openrisc/] [tags/] [gnu-src/] [binutils-2.20.1/] [binutils-2.20.1-or32-1.0rc1/] [gprof/] [TODO] - Diff between revs 205 and 521

Only display areas with differences | Details | Blame | View Log

Rev 205 Rev 521
- add support for prof file format so that prof files can be displayed
- 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
  at the line-level (this is useful for the uprofile tool under DEC's
  OSF/1)
  OSF/1)
- take a hard look at --file-ordering (broken) and --function-ordering
- take a hard look at --file-ordering (broken) and --function-ordering
+ documentation
+ documentation
+ optimize bfd_find_nearest_line_num() (or replace by different interface)
+ optimize bfd_find_nearest_line_num() (or replace by different interface)
+ cleanup _bfd_ecoff_find_nearest_line_num() fixes & description
+ cleanup _bfd_ecoff_find_nearest_line_num() fixes & description
+ ensure "cc -pg" produces good files under OSF/1 v3.0
+ ensure "cc -pg" produces good files under OSF/1 v3.0
+ make sure gprof works together with OSF/1 v3.0's profiling libraries
+ make sure gprof works together with OSF/1 v3.0's profiling libraries
+ implement symtab_parse(); modify sym_lookup() to consider addr_high
+ implement symtab_parse(); modify sym_lookup() to consider addr_high
+ change gprof.c to collect lists, then invoke symtab_parse() for
+ change gprof.c to collect lists, then invoke symtab_parse() for
  each list
  each list
+ Questions:
+ Questions:
        o is -c (--static-call-graph) useful at all?  i can't see
        o is -c (--static-call-graph) useful at all?  i can't see
          how; if it were deleted, gprof would be completely machine
          how; if it were deleted, gprof would be completely machine
          independent => yup, it is
          independent => yup, it is
        o are (long) option names appropriate?
        o are (long) option names appropriate?
        o -k (--exclude-arc) cannot be implemented with getopt();
        o -k (--exclude-arc) cannot be implemented with getopt();
          is new syntax (-k from/to) acceptable?  If not, how to
          is new syntax (-k from/to) acceptable?  If not, how to
          fix it?
          fix it?
        o in the FSF output, the call-graph index now prints
        o in the FSF output, the call-graph index now prints
          the filename of static functions in parentheses; e.g.,
          the filename of static functions in parentheses; e.g.,
          static function foo() that is defined in file bar.c
          static function foo() that is defined in file bar.c
          would be printed as:
          would be printed as:
                        [4] foo (bar.c)
                        [4] foo (bar.c)
          is this acceptable?  should it be done only optionally?
          is this acceptable?  should it be done only optionally?
        o symbols with addresses that map back to a different
        o symbols with addresses that map back to a different
          name are suppressed (happens with labels, for example);
          name are suppressed (happens with labels, for example);
          is this acceptable?  should it be done only optionally?
          is this acceptable?  should it be done only optionally?
+ generalize to allow arbitrary histograms (not just time histograms)
+ generalize to allow arbitrary histograms (not just time histograms)
+ basic-block information currently replaces all symbols created from
+ basic-block information currently replaces all symbols created from
  the core because of an ugly ordering conflict---for now, the current
  the core because of an ugly ordering conflict---for now, the current
  solution works, but something cleaner is desirable ==> cleaned up,
  solution works, but something cleaner is desirable ==> cleaned up,
  but it's slower now
  but it's slower now
+ convert to very new file format (back to trivial format, that is :)
+ convert to very new file format (back to trivial format, that is :)
+ replace "dummy.h" for Alpha (if there is any use to it)
+ replace "dummy.h" for Alpha (if there is any use to it)
+ add support for execution time profiling at a basic-block level
+ 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
+ fix filename-off-by-one bug for Alpha (see ~/tmp/d.[ch])---no longer
  relevant
  relevant
+ "-pg -a" doesn't work as expected because mcleanup() will overwrite
+ "-pg -a" doesn't work as expected because mcleanup() will overwrite
  the file generated by __bb_exit_func() (or vice versa)
  the file generated by __bb_exit_func() (or vice versa)
+ first basic-block of fac() seems to get credited to last basic-block
+ first basic-block of fac() seems to get credited to last basic-block
  of previous function => bug in basic_blocks.c
  of previous function => bug in basic_blocks.c
+ flat profile should provide automatic scaling for per-call times because
+ 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
  otherwise they'll always be zero on a fast machine with tons of small
  functions
  functions
+ make "-a" imply to retain line number info (without actually generating
+ make "-a" imply to retain line number info (without actually generating
  the debugging information (unless -g is specified)---no, this is a
  the debugging information (unless -g is specified)---no, this is a
  bad idea, because it is not clear what level of debugging info should
  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
  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
+ add long options support (or at least use getopt instead of ad-hoc
  implementation)
  implementation)
+ split into files according to abstract objects that are manipulated
+ split into files according to abstract objects that are manipulated
+ replace sccsid by rcsid & add "end of ..." to every .c file
+ replace sccsid by rcsid & add "end of ..." to every .c file
+ use DBG() everywhere
+ use DBG() everywhere
+ fix spacing (" ," -> "," etc.)
+ fix spacing (" ," -> "," etc.)
+ use DEFUNs everywhere
+ use DEFUNs everywhere
+ make compile cleanly with -Wall
+ make compile cleanly with -Wall
+ "gcc -pg -O2" doesn't work on tecc.c unless -fno-omit-frame-pointer is
+ "gcc -pg -O2" doesn't work on tecc.c unless -fno-omit-frame-pointer is
  specified; find out why
  specified; find out why
+ make things portable (prototypes, const, etc.)
+ make things portable (prototypes, const, etc.)
+ if NEW_GMON_OUT is not defined, have a flag that will allow to
+ 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
  read new gmon.out style files.  The idea being that everyone
  will use the new format for basic-block style profiling but
  will use the new format for basic-block style profiling but
  the old format for regular gpprofiling
  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.