[Ns-bugs] [Bug 71] New: DEBUG function tracing issue needs resolved
bugzilla-daemon@nsnam-www.ece.gatech.edu
bugzilla-daemon at nsnam-www.ece.gatech.edu
Tue Aug 21 23:33:52 PDT 2007
http://www.nsnam.org/bugzilla/show_bug.cgi?id=71
Summary: DEBUG function tracing issue needs resolved
Product: ns-3
Version: pre-release
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P1
Component: simulation core
AssignedTo: ns-bugs at isi.edu
ReportedBy: tomh at tomh.org
multicast code has raised some open questions about the use of NS_DEBUG and
possible interaction with the tracing system:
- whether NS_DEBUG should be used widely to perform function call tracing for
debugging during model development
- whether traces such as function call tracing should be hooked into the
tracing system rather than the debug system
- whether function call tracing is explicit or automated (bozo-profiler)
- format of function call tracing including whether parameters are included and
also class namesaaa
- whether more granularity (per-node) is needed in filtering NS_DEBUGs printing
out
- whether NS_DEBUG messages should print out simulation time and possibly node
or object identifiers
- whether NS_DEBUG needs a few logging levels such as syslog warn, info, etc.
For instance: 1: function call/signature tracing, 2: return values, 3:
internal high-level logic of a routine such as an algorithm, 4: logic inside
for loops, etc.
Quote from Craig: "Assume for a moment that a debug trace facility is very
useful. We
currently have one based on macros with an on-off selector. We also have a
very powerful low-level tracing subystem. Does it make sense to integrate
the existing debug print / trace functionality into the tracing subsystem to
leverage some of the flexibility inherent in that system?"
"
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the Ns-bugs
mailing list