Hi,
On Sunday 09 March 2008, waseem wrote:
> At moment i anticipate it could be done in following two ways.
>
> 1). inserting some sort of macro in file myTest.C so that when ever we
> encounter it we know that following function is an event.
This macro would be a Valgrind client request, as I a
On Friday 07 March 2008, waseem wrote:
> Hello Friends,
> I am working with Embla which is a data dependency
> analysis tool and uses Valgrind for its operation. As in an C/C++ program
> there could be number of methods/procedures/ functions that could be
> called. I am in
On Monday 03 March 2008, Julian Seward wrote:
> I intend to merge the DATASYMS branch to trunk shortly.
Hi Julian,
some time ago there was the wish for a call tree trace similar to
strace/ltrace via valgrind. Can your machinary help to add parameter
name/type information the such a call tree trac
On Tuesday 26 February 2008, Julian Seward wrote:
> just need to disable superblock formation. Put this in the post_clo_init
> function:
>
> VG_(clo_vex_control).guest_chase_thresh = 0;
>
> btw, Josef, I see you also have
>
> VG_(clo_vex_control).iropt_unroll_thresh = 0;
>
> why is that?
On Tuesday 26 February 2008, Konstantin Serebryany wrote:
> On Tue, Feb 26, 2008 at 12:58 PM, Josef Weidendorfer
> <[EMAIL PROTECTED]> wrote:
> > On Tuesday 26 February 2008, Konstantin Serebryany wrote:
> > > Does valgrind instrument each routine completely before star
On Tuesday 26 February 2008, Konstantin Serebryany wrote:
> >> At instrumentation time, check if a given instruction is the first
> of a function according to debug information.
> Is that reliable?
> Does valgrind instrument each routine completely before starting
> another routine (I beg my pardon
On Friday 22 February 2008, Konstantin Serebryany wrote:
> Hi,
>
> A question similar to the one discussed in 'thread-change callback' thread.
> How can I see context change events (i.e. when some thread enters or
> exits a function)?
Possibilities:
* At instrumentation time, check if a given in
On Friday 22 February 2008, Julian Seward wrote:
> > > > trace_start_client_code
> > > > track_stop_client_code
> ...
> > > The above is not sufficient.
> ...
> I am (very) surprised to hear that track_{start,stop}_client_code
> give wrong results. The reason is that (translations of) client co
Hi,
On Friday 22 February 2008, Bart Van Assche wrote:
> > > This would be useful for exp-drd too. What I do now is to compare the
> > > result of VG_(get_running_tid)() with a cached value in order to
> > > detect when Valgrind scheduled another thread. This test is performed
> > > upon every
On Wednesday 06 February 2008, Nicholas Nethercote wrote:
> On Tue, 5 Feb 2008, Josef Weidendorfer wrote:
>
> > How similar is the format for VCov to cachegrind's? I suppose this
> > only needs a further "event" for a source line: whether there is debug info
&
Hi Nick,
On Monday 04 February 2008, Nicholas Nethercote wrote:
> I've written an experimental Valgrind coverage tool, called VCov. To try it
> out, do this:
Cool.
Especially the debug info iterators are a very nice addition to the tool
interface.
I did not check it out yet, but will do soon.
On Sunday 13 January 2008, Nicholas Nethercote wrote:
> On Fri, 11 Jan 2008, Josef Weidendorfer wrote:
>
> > An interesting thing for cachegrind/callgrind would be to get global figures
> > on cache events related to data names. This would involve calling
> > VG_(get_
On Friday 11 January 2008, Konstantin Serebryany wrote:
> Dear valgrind developers,
>
> How do you usually profile valgrind tools?
>
> I tried to profile a particularly long run of helgrind with oprofile.
> The test runs ~1 second on a real CPU and fails after few hours under
> helgrind.
> The fl
On Thursday 10 January 2008, [EMAIL PROTECTED] wrote:
> Uninitialised byte(s) found during client check request
> at 0x4005FE: croak (dsyms2.c:23)
> by 0x40066D: main (dsyms2.c:49)
> Address 0x601043 is 7 bytes inside global var "global_i2"
>
> Not terribly useful, but it's a start.
It
On Monday 03 December 2007, Julian Seward wrote:
> The repo's trunk is now in a freeze state until the final release.
> Please don't commit anything in trunk until then. As is usual,
> at the point of the final release, a 3_3_0_BRANCH will be created
> and the trunk will be unfrozen.
Hi Julian,
On Friday 23 November 2007, [EMAIL PROTECTED] wrote:
> Author: njn
> Date: 2007-11-23 01:41:32 + (Fri, 23 Nov 2007)
> New Revision: 7202
>
> Log:
> Fixed up the log file mess throughout, including the docs. This killed
> --log-file-qualifier and --log-file-exactly.
Thanks!
> +// - Get Josef
On Saturday 17 November 2007, Julian Seward wrote:
> I would prefer to use ( ) instead of { } around VAR. { and }
> interact really badly with shells and are generally a pain to
> work with.
Hmm.. Is ( and ) really better?
[EMAIL PROTECTED]:~> echo %q{foo}
%q{foo}
[EMAIL PROTECTED]:~> echo %q
On Saturday 17 November 2007, Nicholas Nethercote wrote:
> On Fri, 16 Nov 2007, Josef Weidendorfer wrote:
>
> > I am not really settled about "--out-file". I just think that options for
> > similar functions in different tools should show some consistency.
> >
On Thursday 15 November 2007, Nicholas Nethercote wrote:
> On Thu, 15 Nov 2007, Josef Weidendorfer wrote:
>
> > The "global single option" was meant to be about the output file only.
> > Of course there also is a log output that already can be redirected
> > with
On Thursday 15 November 2007, Nicholas Nethercote wrote:
> On Thu, 15 Nov 2007, Josef Weidendorfer wrote:
>
> >> Overall, we'd have a --log-file option for normal Valgrind output (ie.
what
> >> normally goes to stderr), and then for each tool that writes an
On Thursday 15 November 2007, Nicholas Nethercote wrote:
> I didn't really follow that, but it seems like Callgrind produces multiple
> output files. They all have a common prefix, and then each one has a
> different suffix. When it comes to processing them, presumably you give
> callgrind_ann
On Monday 12 November 2007, Nicholas Nethercote wrote:
> On Mon, 12 Nov 2007, Ashley Pittman wrote:
>
> > Typically with parallel applications you launch many copies of the same
> > program with the same command line parameters, the MPI implementation
> > itself numbers the processes from 0 to N-1
On Friday 02 November 2007, [EMAIL PROTECTED] wrote:
> Author: njn
> +// - Massif out file:
> +// default --> cachegrind.out.
> +// --cg-out-file=X --> X.
> +// --cg-out-file-exactly=X --> X
> +//
On Wednesday 10 October 2007, Nicholas Nethercote wrote:
> On Mon, 8 Oct 2007, Dirk Mueller wrote:
>
> >> Tools that required big core changes would be less likely to be accepted,
> >> although it would be decided on a case-by-case basis.
> >
> > how do you think should this look like? accept core
24 matches
Mail list logo
