Initial GNU binutils 2.6 import

1 files changed, 72 insertions, 0 deletions

diff --git a/gnu/usr.bin/binutils/gprof/TODO b/gnu/usr.bin/binutils/gprof/TODO
new file mode 100644
index 00000000000..30a3cb25c02
--- /dev/null
+++ b/gnu/usr.bin/binutils/gprof/TODO
@@ -0,0 +1,72 @@
+Thu Feb  9 16:48:04 1995
+
+- documentation
+- optimize bfd_find_nearest_line_num() (or replace by different interface)
+- gmon_io.c cannot deal with target architecture that have a pointer size
+  that is different from the host architectures pointer size---fix this
+  (gmon_out.h, and gmon_io.c)
+- 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)
+
++ 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