I think this looks good. I'll test it tonight my time (UTC+2) but as Josh already said, his changes and my changes are bascially the same except for the memory layout so I don't think there are any problems.
[re-ccing sbcl-devel, because this really should be discussed there.]
On Thu, May 6, 2010 at 10:32 PM, Josh Elsasser wrote:
> I cleaned up and did some quick testing of my old PPC branch, it
> doesn't look hugely different than your changes. The most significant
> change would probably be the address space locations. I don't remember
> the exact reason I used the addresses I did, but I remember being
> concerned that someone might build a kernel with MAXDSIZ bumped up to
> 1GB like it is on i386.
> Here's a diff of my changes against 220.127.116.11:
This, I mostly like. Two questions, though. First, would you mind
resolving the comment "XXX JRE test this with a 1GB MAXDSIZ kernel"
for the heap space parameters? Even just re-wording it to explain what
the concern is would be an im! provement over the rather cryptic note
there. Second, can you explain the logic behind the test/foreign.test.sh
Beyond that, I'd be inclined to commit this if you and Bruce can agree
that it works.
> There are several dynamic-extend test failures which I don't remember
> from before, I had to disable one of them to avoid dropping into the
> debugger during the test run. The failing timer tests are normal for
I can confirm that everything but the timer and float errors are normal for
PPC/linux. I'm not sure about the float tests, as I haven't looked deeply
enough at floating point in general to start diagnosing it.
As far as the other test results go, you might like to know why they fail:
> Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-346)
> Expected failure: debug.impure.! lisp / (UNDEFINED-FUNCTION BUG-353)
These two tests fail because the undefined-function trampoline function is not
considered a valid lisp pointer by the debugger, thus causing the frame to show
up as "bogus stack frame" instead of "undefined function" in the backtrace.
The bug-346 case also fails because the heuristic used for detecting an
incompletely-set-up stack frame doesn't work reliably and causes truncated
backtraces when it fails.
> Expected failure: debug.impure.lisp / (TRACE ENCAPSULATE NIL)
> Expected failure: debug.impure.lisp / (TRACE-RECURSIVE ENCAPSULATE NIL)
The breakpoint functionality that underlies these two tests was never properly
implemented for PPC.
> Failure: dynamic-extent.impure.lisp / (NO-CONSING DX-RAW-INSTANCES)
> Failure: dynamic-extent.impure.lisp / DX-COMPILER-NOTES
&! gt; Failure: dynamic-extent.impure.lisp / HANDLER-CASE-EATING-STACK
> Failure: dynamic-extent.impure.lisp / RECHECK-NESTED-DX-BUG
I suspect that these, and the disabled bogus-compiler-note test, are
made for x86oid dynamic-extent that were never implemented for PPC (or for other
non-x86oid platforms, most likely). The dropping-to-debugger thing is
at least partly
from 18.104.22.168, when impure tests were run via run-program instead of
the board (I have a partial fix in one of my trees that causes an
instead of dropping to debugger, which at least prevents the test
suite from hanging).
> Expected failure: packages.impure.lisp / USE-PACKAGE-CONFLICT-SET
> Expected failure: packages.impure.lisp / IM! PORT-SINGLE-CONFLICT
These are both set :fails-on :sbcl. They are testing for the behavior
between more than two symbols with the same name at once, and expect a slightly
nicer user experience than SBCL provides.
> Expected failure: run-program.impure.lisp / (RUN-PROGRAM INHERIT-STDIN)
This also dates back to 22.214.171.124, something about SIGTTIN and process groups,
and other stuff that I've been able to make neither heads nor tails of.
Anyway, that's my impression of the proposed patch and an explanation of what's
what with the test suite.
-- Alastair Bridgewater