Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2008-01-16 03:05:13 GMT
Results unchanged from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ...
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2008-01-16 03:15:04 GMT
Results unchanged from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ..
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2008-01-16 03:10:10 GMT
Results unchanged from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests ..
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2008-01-16 03:00:05
GMT
Results unchanged from 24 hours ago
Checking out valgrind source tree ... done
Configuring valgrind ... done
Building valgrind ... done
Running regression tests
Author: sewardj
Date: 2008-01-15 23:58:21 + (Tue, 15 Jan 2008)
New Revision: 7351
Log:
Tidy up readdwarf.c: don't pass around information which is also in
the DebugInfo* anyway.
Modified:
branches/DATASYMS/coregrind/m_debuginfo/priv_readdwarf.h
branches/DATASYMS/coregrind/m_debuginfo/re
> [...] change SVal to 64-bit at some point (I vote for it!),
I already did that in Nov 07, but did not commit due to increase
in run time and space usage. The resulting patch is attached.
It allows up to 24 bits for lock- and thread-set IDs. I can't
remember now why I limited it to 24 bits --
>
>
> So the only new method is to change HG_(initIterFM) (maybe better to
> make a new one, HG_(initAtIterFM)). That requires to understand the
> FM iteration mechanism. Not difficult, but I did not find the time
> to study it.
>
> J
>
If you don't mind, I'll implement this one and send you the
On Tuesday 15 January 2008 10:32, Konstantin Serebryany wrote:
> You mean it requires 32-bit hardware? or 32-bit-only os? or 32-bit
> executable?
I _think_ requires 32-bit executable.
> I don't have any 32-bit-only hardware at the moment, so I can't check :)
> Anyway, I've sent the question to op
> I found out that ~85% of helgrind's time (on one of my tests) is spent in
> the following loop:
Yes. I saw a similar problem running OOo on Helgrind.
> ...
>/* FIXME: don't iterate over the complete lock set */
>HG_(initIterFM)( map_locks );
>while (HG_(nextIterFM)( map_locks,
>
You mean it requires 32-bit hardware? or 32-bit-only os? or 32-bit
executable?
I don't have any 32-bit-only hardware at the moment, so I can't check :)
Anyway, I've sent the question to oprofile folks already.
--kcc
On Jan 15, 2008 12:19 PM, Julian Seward <[EMAIL PROTECTED]> wrote:
> On Tuesday
Hi Julian, all,
I found out that ~85% of helgrind's time (on one of my tests) is spent in
the following loop:
static void shadow_mem_make_NoAccess ( Thread* thr, Addr aIN, SizeT len )
...
/* FIXME: don't iterate over the complete lock set */
HG_(initIterFM)( map_locks );
while (HG_(nextI
On Tuesday 15 January 2008 10:04, Konstantin Serebryany wrote:
> Thanks for the answers!
> oprofile is indeed very useful, but unfortunately I can't make the
> call-graph (something wrong with my oprofile setup).
I think oprofile cannot do call-graph on 64-bit x86, only on
32-bit x86. I have succ
Thanks for the answers!
oprofile is indeed very useful, but unfortunately I can't make the
call-graph (something wrong with my oprofile setup).
Anyway, I found the guilty place in helgrind by manually inserting counters
in the code. Details follow in separate thread.
--kcc
On Jan 13, 2008 2:26 AM,
Author: sewardj
Date: 2008-01-15 08:42:56 + (Tue, 15 Jan 2008)
New Revision: 7350
Log:
Intercept memcpy on 64-bit ld.so's.
Modified:
trunk/memcheck/mc_replace_strmem.c
Modified: trunk/memcheck/mc_replace_strmem.c
===
--- tru
14 matches
Mail list logo
