[Ltrace-devel] new ARM failures

[Petr Machata]

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