07.12.2010 09:09, Zach Welch wrote:
Running ./ltrace.main/parameters.exp ...
FAIL: func_double(3.40*, -3.40*).*= -3.40* in
/scratch/zwelch/ltrace/testsuite/ltrace.main/parameters.ltrace for 0
times ,should be 1
FAIL:<... func_call resumed> \"x\", \"y\") in
/scratch/zwelch/ltrace/testsuite/ltrace.main/parameters.ltrace for 0
times ,should be 1
[...]
Personally, I would like to see these fixed before a new release is
produced, as they all represent recent regressions that could be
avoided. At the very least, the patches that have caused these problems
Unless I'm mistaken, those above are not really regressions. They are
new tests for things that never worked. If the goal is to put out a
release that passes its own test suite, then all that's needed is to
comment out the right lines in parameters.exp. But I'd rather keep the
code itself in tree.
can be deferred until a later release, but I would be happier to see
these fixed properly.
FWIW, the fixes for passing double on 32-bit machines is here:
https://github.com/pmachata/ltrace/tree/pmachata
This branch may need re-seating after recent changes to tree history.
That should take care of the first failure that you cited.
The second problem is more involved and I never really investigated it
properly. That test case is written to test that ltrace can fetch
on-return arguments even in face of nested call. I think this should
now work on ppcs and x86_64, whose argument passing is based on
registers, but it fails mysteriously on arches that pass arguments via
stack (not sure about i386 though). From the cursory look that I took,
it seemed to me that the stack slot that we want to extract the value
from was reused or rewritten between the calls.
PM
_______________________________________________
Ltrace-devel mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/ltrace-devel
