From: Larry V. <re...@us...> - 2010-02-05 14:14:05
|
Larry Valkama skrev: >> On Thu, Feb 4, 2010 at 2:53 PM, Larry Valkama >> <re...@us...> wrote: >>> Larry Valkama skrev: >>>> I say maybe because it could be done cleaner (if deftype >>>> generation-index is defined). >>>> >>>> /larry >>> bump.. mips still not building at 1.0.35.2 >>> >>> also se patch from Bruce O'Neel at 2009 dec 28. >>> >>> best regards, >>> /larry >> Thank you. Applied as 1.0.35.4. >> >> Gabor >> > > Thanks! > > Another issue on mips is the signal-11 given during build of PCL. Please > correct me if I get anything wrong. > > The reason for this is that mips has always signalled 11 during PCL > build (tracing back to around 1.0.18). Somewhere on the road the build > script was added an lose-on-corruption flag. After this it will refuse > to continue when signal-11 is given on mips. > > The reason for this is that PCL gets an type error condition (not sure > what to call it). > > This in turn triggers the debugger to start. The debugger starts walk > the stack and print out the backtrace. > > When it reach the bottom it will hit a stack-frame that contains an LRA > that is calculated in src/runtime/mips-assem.S:call_into_lisp. > > This LRA is calculated of an label that is aligned to 3. > All this makes the LRA to look like an non-fixnum. > > Because it doesn't look like an fixnum > src/code/debug-int.lisp:compute-calling-frame will treat the LRA as an > data structure. Whereas it is really only pointing to machine-code. This > leads to bogus data when trying to reference that structure. And when > reading the bogus data, it signals 11. > > PPC and Alpha align by 3. Sparc align by 8. > > How can PPC/Alpha survive the build, when it looks like they should hit > the same problem? > > Was thinking if PPC/Alpha also try to read at wrong address but doesn't > sigsegv and therefore doesn't lose-on-corruption. (Maybe they sigbus or > something that isn't corruption-losable (is it?)). > > Why is sparc different? > > Possible patch ( ie, it works for me, but not sure if it is the right > thing to do ): > > diff --git a/src/runtime/mips-assem.S b/src/runtime/mips-assem.S > index c295993..2492bcc 100644 > --- a/src/runtime/mips-assem.S > +++ b/src/runtime/mips-assem.S > @@ -179,7 +179,7 @@ symbol: > /* Jump into lisp land. */ > jr reg_LIP > > - .align 3 > + .align 4 > .set noreorder > lra: .word RETURN_PC_HEADER_WIDETAG > > > Corrections: On mips we are receiving signal-10 which is a SIGBUS. ; SYS:SRC;PCL;FIXUP.FASL.NEWEST written ; compilation finished in 0:00:06.460 CORRUPTION WARNING in SBCL pid 18434: Signal 10 received The integrity of this image is possibly compromised. Exiting. Error opening /dev/tty: No such device or address Welcome to LDB, a low-level debugger for the Lisp runtime environment. ldb> kill -l: 5) SIGTRAP 8) SIGFPE 10) SIGBUS Now, "Signal 10 received" is recognized in interrupt.c void interrupt_handle_now_handler(int signal, siginfo_t *info, void *void_context) ... corruption_warning_and_maybe_lose("Signal %d received", signal); Which is installed by: interrupt.c install_handler(int signal, void handler(int, siginfo_t*, os_context_t*)) { ... sa.sa_sigaction = interrupt_handle_now_handler; That is called by: target-signal.lisp (define-signal-handler sigbus-handler "bus error") And I see no treatment of sigbus in ppc-arch.c or mips-arch.c, so I guess that is the only mechanism that is handling sigbus. cheers, /larry |