Re: [Sbcl-devel] [Sbcl-commits] master: x86-64, struct-by-value: correctly pass small structs on the stack

[Stas B. <sta...@gm...>]

Does the ABI say anything about extent? Copying the whole struct is
easy, but maybe the caller doesn't care what happens to the original
struct and can avoid copying.

On Sat, Apr 25, 2026 at 12:16 AM Jesse Bouwman
<jes...@pr...> wrote:
>
> Over-reads (and write) are a clear problem: the load VOPs only operate on multiples of 8-bytes and happily read across page boundaries. I made a 2-page RW/NONE harness for this, and have tests plus a fix in progress.
>
> Also, about copying pointers to stack, that's exactly what both ABIs say: the callee owns the memory. Do you have ideas about behavior here? I can't think of anything to do.
>
> > On Apr 23, 2026, at 2:49 PM, Stas Boukarev <sta...@gm...> wrote:
> >
> > One issue I'm not sure how to solve (or whether to solve) is that in
> > C, structs traveling by memory can't be done by just passing a pointer
> > to some existing struct.
> > They get copied to a new stack location.
> > It would be good to control whether that happens, but maybe the ABI
> > says "this region is now mine, anything can be done with it".
> >
> > On Fri, Apr 24, 2026 at 12:40 AM Jesse Bouwman
> > <jes...@pr...> wrote:
> >>
> >> Stas, if you want to send me a list of findings and test gaps, I will put time into closing them out -- just raw notes or LLM findings are enough.
> >>
> >> Jesse
> >>
> >>> On Apr 23, 2026, at 2:25 PM, Stas Boukarev <sta...@gm...> wrote:
> >>>
> >>> The struct-by-value issues keep coming and coming, I'm already tired
> >>> of fixing them, have no strength to add proper tests.
> >>> And it also needs to test for over-reading input structures, I have
> >>> some scaffolding from the time of writing simd routines which mmaps
> >>> data at the edges of a protected region.
> >>>
> >>> On Thu, Apr 23, 2026 at 11:17 PM Christophe Rhodes <cs...@ca...> wrote:
> >>>>
> >>>> Stas Boukarev <sta...@gm...> writes:
> >>>>
> >>>>> I just send c-call.lisp to various free LLMs and say "find bugs here".
> >>>>> And also make them generate test cases.
> >>>>> I didn't include any specific test because they won't find new
> >>>>> problems.
> >>>>
> >>>> Sure, but they'll help the day someone wants to make struct-by-value
> >>>> work on platforms that don't support it yet.  (Maybe in this grand
> >>>> future that's less necessary because we'll just send riscv's c-call to
> >>>> some LLM and say "now implement the struct-by-value ABI please".)
> >>>>
> >>>>> A test that performs an exhaustive combination of different foreign
> >>>>> types is needed.
> >>>>> But I'm not eager to make that yet.
> >>>>
> >>>> ... that would work too, sure.  I can be patient.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Christophe
> >>>
> >>>
> >>> _______________________________________________
> >>> Sbcl-devel mailing list
> >>> Sbc...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/sbcl-devel
> >>
> >>
>
>