|
From: Julian S. <js...@ac...> - 2005-09-28 11:09:01
Attachments:
new_module_graph.ps.bz2
|
Attached is the coregrind/ module graph following r4806. It's big and ugly, but not as big and ugly as it was before :-) Now (for the first time!) m_main is at the top of the graph, rather than in the middle of a huge cycle, and m_aspacemgr is nearly at the bottom, as intended. The trivia-obsessed may be amused to observe that the harmless-sounding m_libcassert (purveyor of vg_assert) is now right in the middle of a giant tangle of modules, due to our insistence on printing fully- annotated stack backtraces at assertion failures. [This is a conscious design choice, so no harm there, but it's interesting to see.] J |
|
From: Nicholas N. <nj...@cs...> - 2005-09-28 14:44:14
|
On Wed, 28 Sep 2005, Julian Seward wrote: > Attached is the coregrind/ module graph following r4806. It's > big and ugly, but not as big and ugly as it was before :-) > > Now (for the first time!) m_main is at the top of the graph, > rather than in the middle of a huge cycle, and m_aspacemgr is > nearly at the bottom, as intended. The trivia-obsessed may be > amused to observe that the harmless-sounding m_libcassert > (purveyor of vg_assert) is now right in the middle of a giant > tangle of modules, due to our insistence on printing fully- > annotated stack backtraces at assertion failures. [This is a > conscious design choice, so no harm there, but it's interesting > to see.] That could be fixed by having an init() function for m_libcassert and passing in pointers to pp_sched_status and VG_(get_StackTrace2) and VG_(pp_StackTrace). Nick |