On Thu, May 06, 2010 at 11:51:53PM -0400, Alastair Bridgewater wrote:
> [re-ccing sbcl-devel, because this really should be discussed there.]
> On Thu, May 6, 2010 at 10:32 PM, Josh Elsasser <josh@...> 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 126.96.36.199:
> > http://www.elsasser.org/misc/sbcl-obsd-ppc.diff
> 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 improvement over the rather cryptic
> note there.
That was a note to me to test with a kernel build with the 512MB hard
data size limit bumped to 1GB, which affects how virtual address space
is laid out. It's probably silly to worry about this though.
> Second, can you explain the logic behind the test/foreign.test.sh
On OpenBSD that test fails spectacularly if the library isn't build
with -fPIC. Is this not necessary on other PPC platforms?
> 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 OpenBSD.
> 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.
I'll see if I can look into the float problems again. I remember it
had something to do with float-related exceptions never being
signaled, perhaps because SIGFPE was never delivered.
> 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
> > ?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
> from changes 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
> 188.8.131.52, when impure tests were run via run-program instead of
> fork() across the board (I have a partial fix in one of my trees
> that causes an unhandled exception instead of dropping to debugger,
> which at least prevents the test suite from hanging).
Avoiding the debugger would be nice, especially for someone who does
automated build and test runs.
> > ?Expected failure: ? ?packages.impure.lisp / USE-PACKAGE-CONFLICT-SET
> > ?Expected failure: ? ?packages.impure.lisp / IMPORT-SINGLE-CONFLICT
> These are both set :fails-on :sbcl. They are testing for the
> behavior of name-conflicts 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 184.108.40.206, 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.
Thanks for the rundown. I was mostly concerned about OpenBSD-specific
test failures, but I suppose it would also be nice to try and fight
the PPC bitrot a bit and fix some of those other test failures.