[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [valgrind] [Bug 371916] execution tree xtree concept
From:       Josef Weidendorfer <bugzilla_noreply () kde ! org>
Date:       2016-11-08 23:53:09
Message-ID: bug-371916-17878-tG0UT7Me0z () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=371916

Josef Weidendorfer <josef.weidendorfer@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |josef.weidendorfer@gmx.de

--- Comment #15 from Josef Weidendorfer <josef.weidendorfer@gmx.de> ---
Hi Philippe, nice patch!

I think it is good to move functionalty from tools to the core, if it
can make other tools better or easier to write. Attaching data to call
trees built from stack traces should fit here.
However, I did not check the large rewrite of massif.

General comments (I may be missing something here):

* is this bound to memory allocation, or is memory allocation just
  an example use case of the API? It would be nice if tools could
  attach arbitrary data to xtrees. Perhaps separate the memory allocation
  stuff into different files (e.g. xtree_memalloc.h).

* behavior of some functions in the XTree API depend on command line
  options. Wouldn't it be better for a tool using this API to be in
  full control here, ie. the tool parses command line
  options and pass them as flags?  About the changes in the malloc
  wrappers, I think it would be better if the tool can register handlers,
  and these handlers then call e.g. VG_(XTMemory_Full_alloc).

About the XTree API, why do you need these add/sub variants?
Why not just have a function to get a pointer to the value to be updated?
Any reduction operation may be useful, such as min/max.

-- 
You are receiving this mail because:
You are watching all bug changes.=
[prev in list] [next in list] [prev in thread] [next in thread]