From: Cyrus H. <ch...@bo...> - 2005-10-10 07:07:52
|
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... Thanks again, Cyrus On Oct 9, 2005, at 11:29 PM, Christophe Rhodes wrote: > Cyrus Harmon <ch...@bo...> 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 >> point. >> > > 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... > > Cheers, > > Christophe > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |