Larry Valkama skrev:
>> On Thu, Feb 4, 2010 at 2:53 PM, Larry Valkama
>> <remlali@...> wrote:
>>> Larry Valkama skrev:
>>>> I say maybe because it could be done cleaner (if deftype
>>>> generation-index is defined).
>>> bump.. mips still not building at 188.8.131.52
>>> also se patch from Bruce O'Neel at 2009 dec 28.
>>> best regards,
>> Thank you. Applied as 184.108.40.206.
> 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
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.
Error opening /dev/tty: No such device or address
Welcome to LDB, a low-level debugger for the Lisp runtime environment.
Now, "Signal 10 received" is recognized in interrupt.c
interrupt_handle_now_handler(int signal, siginfo_t *info, void
corruption_warning_and_maybe_lose("Signal %d received", signal);
Which is installed by:
install_handler(int signal, void handler(int, siginfo_t*, os_context_t*))
sa.sa_sigaction = interrupt_handle_now_handler;
That is called by:
(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.