Re: lang/* BTI breakage - lang/sbcl

On Fri, Jun 30, 2023 at 10:21:30AM +0100, Stuart Henderson wrote:
> On 2023/06/30 06:47, Sebastien Marie wrote:
> > On Thu, Jun 29, 2023 at 11:19:50PM +0200, Christian Weisgerber wrote:
> > > Since BTI affects any and all compilers that generate executable code,
> > > I tried to build all lang/* ports on amd64 with BTI enabled. Here's the
> > > list of failures:
> > >
> > > [...]
> > > lang/sbcl
> >
> > the 2.3.6 update (already on ports@) adresses it by using USE_NOBTCFI.
>
> I'm ok with that update and taking maintainer FWIW (but I don't run lisp
> things myself).
>
> I guess it also needs a patch to sbcl itself to use nobtcfi when linking
> though, so that sbcl-compiled code also works at runtime? (Or an equivalent
> if it doesn't use the system linker).
>

sbcl compilation works by generating native code inside live managed memory, and
permits to save the whole memory image to a file.

it is why the binary currently also needs WX and RX memory (I intent to work a
bit on it if possible).

When generating an executable, it is copying /usr/local/bin/sbcl binary as base,
and append the (optionally compressed) memory image to the file, to create a
standalone executable.

When the output file is executed, it is reading its own image, loads it in
memory, and use an entrypoint for loaded code.

So the generated file has all the flags it needs to run (because copied from
/usr/local/bin/sbcl binary).
--
Sebastien Marie