|
From: <js...@ac...> - 2006-04-02 02:55:57
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2006-04-02 04:40:00 CEST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 203 tests, 7 stderr failures, 3 stdout failures ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/sh-mem-random (stdout) callgrind/tests/clreq (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/ppc32/mftocrf (stdout) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 202 tests, 8 stderr failures, 2 stdout failures ================= memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/sh-mem (stderr) callgrind/tests/clreq (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/ppc32/mftocrf (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Apr 2 04:48:02 2006 --- new.short Sun Apr 2 04:55:51 2006 *************** *** 8,10 **** ! == 202 tests, 8 stderr failures, 2 stdout failures ================= memcheck/tests/leak-cycle (stderr) --- 8,10 ---- ! == 203 tests, 7 stderr failures, 3 stdout failures ================= memcheck/tests/leak-cycle (stderr) *************** *** 13,15 **** memcheck/tests/pointer-trace (stderr) ! memcheck/tests/sh-mem (stderr) callgrind/tests/clreq (stderr) --- 13,15 ---- memcheck/tests/pointer-trace (stderr) ! memcheck/tests/sh-mem-random (stdout) callgrind/tests/clreq (stderr) |
|
From: Josef W. <Jos...@gm...> - 2006-04-02 12:29:09
|
Hi, On Sunday 02 April 2006 04:55, js...@ac... wrote: > == 203 tests, 7 stderr failures, 3 stdout failures ================= > memcheck/tests/leak-cycle (stderr) > memcheck/tests/leak-tree (stderr) > memcheck/tests/leakotron (stdout) > memcheck/tests/pointer-trace (stderr) > memcheck/tests/sh-mem-random (stdout) > callgrind/tests/clreq (stderr) What is the problem here? Josef |
|
From: Julian S. <js...@ac...> - 2006-04-02 16:13:35
|
The problem is the crazy ppc64-linux ABI. On {x86,amd64,ppc32}-linux,
if f is a function, then &f (in C) is the address of the first instruction
of f (or PLT; at least it's a code address). On ppc64-linux, &f gives
you a pointer to a 3-word function descriptor, the first word of which
is the address of the code.
Therefore, when passing function addresses for code generation to VEX (using
eg unsafeIRDirty_0_N) you need to first apply VG_(fnptr_to_fnentry) to
what you get from the & operator. VG_(fnptr_to_fnentry) is the identity
on {x86,amd64,ppc32}-linux and fetches the first word of the function
descriptor on ppc64-linux. (compare cachegrind, memcheck etc)
I've fixed this particular one (r5814) but now I am wondering why the
rest of callgrind doesn't crash on ppc64-linux. Specifically I see that
insert_simcall() calls unsafeIRDirty_0_N without using VG_(fnptr_to_fnentry),
and I think it only works due to the line "if (helperAddr == 0) return 0;"
and helperAddr is always zero.
Can you look into this?
It would be good to have a regression test which uses as much
of callgrind's functionality as possible (eg --simulate-cache=yes
--simulate-wb=yes --simulate-hwpref=yes) so that more of callgrind
gets tested each night.
J
On Sunday 02 April 2006 13:28, Josef Weidendorfer wrote:
> Hi,
>
> On Sunday 02 April 2006 04:55, js...@ac... wrote:
> > == 203 tests, 7 stderr failures, 3 stdout failures =================
> > memcheck/tests/leak-cycle (stderr)
> > memcheck/tests/leak-tree (stderr)
> > memcheck/tests/leakotron (stdout)
> > memcheck/tests/pointer-trace (stderr)
> > memcheck/tests/sh-mem-random (stdout)
> > callgrind/tests/clreq (stderr)
>
> What is the problem here?
>
> Josef
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Josef W. <Jos...@gm...> - 2006-04-02 17:30:42
|
On Sunday 02 April 2006 18:13, Julian Seward wrote:
> The problem is the crazy ppc64-linux ABI. On {x86,amd64,ppc32}-linux,
> if f is a function, then &f (in C) is the address of the first instruction
> of f (or PLT; at least it's a code address). On ppc64-linux, &f gives
> you a pointer to a 3-word function descriptor, the first word of which
> is the address of the code.
>
> Therefore, when passing function addresses for code generation to VEX (using
> eg unsafeIRDirty_0_N) you need to first apply VG_(fnptr_to_fnentry) to
> what you get from the & operator. VG_(fnptr_to_fnentry) is the identity
> on {x86,amd64,ppc32}-linux and fetches the first word of the function
> descriptor on ppc64-linux. (compare cachegrind, memcheck etc)
Ah, thanks.
Hmm. As unsafeIRDirty_0_N always gets a function pointer as 3rd
parameter, wouldn't it be better to do fnptr_to_fnentry inside
of it, to help tool authors avoid this trap?
> I've fixed this particular one (r5814) but now I am wondering why the
> rest of callgrind doesn't crash on ppc64-linux. Specifically I see that
> insert_simcall() calls unsafeIRDirty_0_N without using VG_(fnptr_to_fnentry),
> and I think it only works due to the line "if (helperAddr == 0) return 0;"
> and helperAddr is always zero.
Yes. By default, there is no cache simulation done at all, so the helper was
always 0. In this case, I have a special case here to still be able to get the
instruction fetches - it is calculated from the number of instruction in a
BB and the execution count of the BBs.
> Can you look into this?
As I see, you've done the second fix, too (r5815).
> It would be good to have a regression test which uses as much
> of callgrind's functionality as possible (eg --simulate-cache=yes
> --simulate-wb=yes --simulate-hwpref=yes) so that more of callgrind
> gets tested each night.
Partly, these use different simulation functions, so I will do
multiple tests.
Are you fine with the added post-test check in the regression
tests? Or am I missing something, and such checks are already
possible with the current framework?
Josef
|
|
From: Julian S. <js...@ac...> - 2006-04-02 18:00:16
|
> Ah, thanks.
> Hmm. As unsafeIRDirty_0_N always gets a function pointer as 3rd
> parameter, wouldn't it be better to do fnptr_to_fnentry inside
> of it, to help tool authors avoid this trap?
Well, maybe, but that pushes ABI-specific details inside vex, which
complicates the interface.
> Partly, these use different simulation functions, so I will do
> multiple tests.
That would be good.
> Are you fine with the added post-test check in the regression
> tests?
It looks OK to me, but it would be good if Nick could have a look
too ("Patch: add a post-test check to the regtest script") as the
original perl script author.
> Or am I missing something, and such checks are already
> possible with the current framework?
No .. such checks are not already possible, as far as I know.
So this sounds like a useful addition.
J
|
|
From: Nicholas N. <nj...@cs...> - 2006-04-02 21:48:48
|
On Sun, 2 Apr 2006, Julian Seward wrote:
>> Are you fine with the added post-test check in the regression
>> tests?
>
> It looks OK to me, but it would be good if Nick could have a look
> too ("Patch: add a post-test check to the regtest script") as the
> original perl script author.
I'll take a look at merging it tonight. I wonder if having a
posttest_filter (like the std{err,out}_filters) would be useful too.
Nick
|
|
From: Josef W. <Jos...@gm...> - 2006-04-02 23:28:55
|
On Sunday 02 April 2006 23:46, Nicholas Nethercote wrote:
> On Sun, 2 Apr 2006, Julian Seward wrote:
>
> >> Are you fine with the added post-test check in the regression
> >> tests?
> >
> > It looks OK to me, but it would be good if Nick could have a look
> > too ("Patch: add a post-test check to the regtest script") as the
> > original perl script author.
>
> I'll take a look at merging it tonight. I wonder if having a
> posttest_filter (like the std{err,out}_filters) would be useful too.
I thought about it, but it is not needed.
The post-test script can do all the filtering itself (and use an
external filter script, too).
Eg. for callgrind, the post-test would call callgrind_annotate on the
generated data, filter the call relationships and call counts, and
print them out.
Even support for an expected output of the post-test is not strictly needed,
as the script could check this for itself. But when the check fails, IMHO
it is good to be able to look at the wrong output.
Thanks,
Josef
|