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

[Jesse B. <jes...@pr...>]

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
>> 
>>