Re: lang/sbcl will not work with x-only

On 2023/01/27 16:02, Josh Elsasser wrote:
> On Fri, Jan 27, 2023 at 05:02:33PM +0100, Christian Weisgerber wrote:
> > lang/sbcl will not work with x-only.
> >
> > I took another look at the warnings about data directives in .text.
> > In runtime/x86-64-assem.S we have snippets like these:
> >
> > GNAME(fun_end_breakpoint_trap):
> > TRAP
> > .byte trap_FunEndBreakpoint
> > hlt # We should never return here.
> >
> > GNAME(do_pending_interrupt):
> > TRAP
> > .byte trap_PendingInterrupt
> > ret
> >
> > GNAME(memory_fault_emulation_trap):
> > TRAP
> > .byte trap_MemoryFaultEmulation
> >
> > Where TRAP is defined to int3, and trap_* are consecutively numbered
> > constants. The other half of this is sigtrap_handler() in
> > runtime/x86-64-arch.c, which reads the byte after the int3 instruction
> >
> > trap = *(unsigned char *)OS_CONTEXT_PC(context);
> >
> > and then dispatches accordingly.
> >
> > ... And this brief analysis marks the end of my own involvement
> > with this port.
>
> Unfortunately I don't have a new enough CPU to test xonly, so someone
> should probably mark it USE_NOEXECONLY

I don't know how sbcl works, but if it calls the OS linker at runtime
when compiling software, it may need to use --no-execute-only on that
call too.

(Also while on the subject of sbcl, we still have "map stack for pid XX
failed" in dmesg when it runs; I don't know how bad that is but sbcl is
the only program which gets run during an i386 ports build which does
that).