[0d0e60]: TODO  Maximize  Restore  History

Download this file

128 lines (112 with data), 5.9 kB

This is an (incomplete) list of some of the stuff we want to look at doing.

If you're interested in hacking on any of these, please contact the list first
for some pointers and/or read HACKING and doc/CodingStyle.

0.8 release
-----------

 o finish opstack: proper output, various --separate= --merge= handling,
  later do we need an opreport like opstack (showing caller/callee at binary
  boundary not symbols) ?
 o first quick test show it works but I got in oprofiled.log (possibly when
  shutdown oprofile)
	Read buffer of 35253 entries.
	Read buffer of 35220 entries.
	Unknown code !
  phe: look like to occur when sampling rate is a bit too high.
 o when samples rate is too high (< 100000) a lot of cpu buffer overflow occur
  then daemon get many problems. I dunno exactly what is wrong but in this case
  a lot of samples file creation fails, many samples are lost due to no mm etc.
  we can prolly make the daemon more robust in this case.

0.9 release
-----------

 o better --verbose, roughly, if possible:
   class verbose { enum verbose_mode { stats, bfd_debug, ... }; }
   verbose stats; verbose bfd_debug;
   cverb << stats << "foo\n";
   cverb << (stats|bfd_debug) << "bar\n";
   cverb << bfd_debug << "bar\n";
   opreport --verbose=stats; opreport --verbose=stats,bfd_debug;
 o opdiff
 o add event aliases for common things like icache misses

Before 1.0 little stuff
-----------------------

 o depedencies between profile_container.h symbol_container.h and
  sample_container.h become more and more ugly, I needed to include them
  in a specific order in some source.
 o test and fix p4 support both for 2.4/2.6, merge HT support for 2.4 to 2.6
  (if I can get a P4 HT box ...)
 o x86_64 and 2.4 kernel: it's apparently broken
 o Alpha ev67 events are broken
 o odb_insert() can fail on ftruncate or mremap() in db_manage.c but we don't
  try to recover gracefully.
 o output column shortname headers for opreport -l
 o separate debug info stuff
 o is relative_to_absolute_path guaranteeing a trailing '/' documented ?
 o create_path API is weird
 o move oprofiled.log to OP_SAMPLE_DIR/current ?
 o lib-image: and image: behavior depend on --separate=, if --separate=library
  opreport "lib-image:*libc*" --merge=lib works but not
  opreport "image:*libc*" --merge=lib whilst the behavior is reversed if
  --separate==none. Must we take care ?
 o --buffer-size is useless on 2.5 without tuning of watershed
 o pp tools must handle samples count overflow (marked as (unsigned)-1)
 o when we dump stats for oprofiled, dump kernel-side values too (for 2.5)
 o the way we show kernel modules in 2.5 is not very obvious - "/oprofile"
 o sample-file: / binary: don't work in any useful way - can we fix this
   by peeking at binary: value and faking the split_sample_file somehow ?

Documentation
-------------

 o more discussion of problematic code needs to go in the "interpreting" section. 
 o document gcc 2.95 and linenr info problems especially for inline functions
 o audit oprof_start for security + then document sudo
 o finish the internals manual

General checks to make
----------------------
 
 o rgrep FIXME
 o valgrind (--show-reachable=yes --leak-check=yes)
 o audit to track unnecessary include <>
 o gcc 3.0/3.x compile
 o Qt2/3 check, no Qt check
 o verify builds (modversions, kernel versions, athlon etc.). I have the
  necessary stuff to check kernel versions/configurations on PIII core (Phil)
 o use nm and a little script to track unused function
 o test it to hell and back
 o compile all C++ programs with STL_port and test them
 o There is probably place of post profile tools where looking at errno will give better error messages.

Later
-----
 
 o we should notice an opcontrol config change (--separate etc.) and
   auto-restart the daemon if necessary (Run)
 o we can add lots more unit tests yet
 o remove 2.2 / gcc 2.91 support ?
 o Itanium event constraints are not implemented
 o side-by-side opreport output (--compare - needs UI spec) ???
 o can we log samples going to anonymous mapping by using
  - 2.6 one fake sample for all anonymous sample, cookie == 0 mean use this
  special sample file. (cookie == -1 or -2 as magic value ?)
  - 2.4 we must pass to daemon note about exec anon mapping and create one
  fake samples file by anon mapping specially named like 
  /{root}/path/to/appli/anon_mapping-0B8000-0BA0000/...
 o GUI still has a physical-counter interface, should have a general one
   like opcontrol --event
 o I think we should have the ability to have *fixed* width headers, e.g. :

vma      samples  cum. samples  %           cum. %     symbol name             image name              app name
0804c350 64582    64582         35.0757     35.0757    odb_insert              /usr/loc...in/oprofiled /usr/local/oprofile-pp/bin/oprofiled

  Note the ellipsis
 o should we make the sighup handler re-read counter config and re-start profiling too ?
 o improve --smart-demangle
	o allow user to add it's own pattern in user.pat, document it.
	o hard code ${typename} regular definition to remove all current limitations (difficult, perhaps after 1.0 ?).
 o oprof_start dialog size is too small initially
 o oprof_start key movement through events doesn't change help text
 o i18n. We need a good formatter, and also remember format_percent()
 o opannotate --source --output-dir=~moz/op/ /usr/bin/oprofiled
   will fail because the ~ is not expanded (no space around it) (popt bug I say)
 o cpu names instead of numbers in 2.4 module/ ?
 o remove 1 and 2 magic numbers for oprof_ready
 o adapt Anton's patch for handling non-symbolled libraries ?
 o use standard C integer type <stdint.h> int32_t int16_t etc.
 o opcontrol --save should allow to backup binary, see subject "features to make oprofile easier to use" on mail list
 o event multiplexing for real
 o XML output
 o profile the NMI handler code
 o merge sample files into one big report (like vtune can do repeated runs)

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks