My reading of this is that the stack alignment as performed by c-
call.lisp is, in a limited sense, right in the sense that the _size_
of the stack frame is right, but that if the stack frame is, say, on
a 0x04-byte boundary before-hand, c-call.c will keep it there, mod
+stack-alignment-bytes+. I don't see anything that attempts to align
the stack to a particular absolute boundary, only stuff that keeps
the new stack frame of an appropriately-aligned size. The problem is
that the lisp code can leave the stack in a state such that just
making sure that the size of the stack frame is a mulitple of 16
isn't good enough. Again, I could totally be reading this wrong, but
that's what I see. I'll keep digging...
On Oct 9, 2005, at 11:29 PM, Christophe Rhodes wrote:
> Cyrus Harmon <ch-sbcl@...> writes:
>> My apologies for not being more explicit about this. Yes, I had done
>> that and, yes, the stack is properly 16-byte aligned at this point.
>> It's the next step, stepping through call_into_lisp and whatever
>> call_into_lisp does where I quickly get over my head.
>> I think Thiemo's point about multiple stacks having multiple
>> alignments sounds reasonable, which would suggest that fixing
>> call_into_lisp isn't the right answer, but rather that making sure
>> that call_into_c is setting up a stack frame that is aligned
>> according to the ABI, if I understand the various stacks right, which
>> I am pretty sure I don't and I'm just making wild guesses at this
> Yeah, that's right. OTOH, there would seem to be code in
> ppc/c-call.lisp which at least tries to get the stack alignment right:
> the very first thing in there is +stack-alignment-bytes+. So your
> task is probably to find where we're missing that in some adjustment
> to nsp-tn...
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> Sbcl-devel mailing list