From: Cyrus H. <ch...@bo...> - 2005-10-09 19:52:38
|
Last week I, in a couple inappropriate places like my blog and an email to Xophe instead of to sbcl-devel, brought up an issue I was having with MacOS where when trying to call Carbon functions from lisp, I was seeing some odd behavior. Gary Byers was kind enough to point out that he had seen something similar with OpenMCL long ago and that the stack needed to be aligned on 16-byte boundaries to keep AltiVec happy. Gary syas: On Oct 5, 2005, at 4:25 PM, Gary Byers wrote: > I don't know how far back John Wiseman's archives go, but lemonodor > used to have (spring/summer of 2002 ?) screenshots of OpenMCL's Cocoa > demo with psychedelic menu and text colors, so the problem looked > familiar. If you have a G3 (which doesn't have AltiVec), you should > find that your code runs without those artifacts there. I haven't tried the G3 thing, as I don't have one handy, but, indeed, GDB suggests that by the time I'm calling Carbon functions like StandardAlert, the stack is aligned on a 4 byte boundary, not a 16- byte boundary: (gdb) info f Stack level 0, frame at 0xbfffc974: pc = 0x93319ed0 in StandardAlert; saved pc 0xc194 called by frame at 0xbfffca14 Arglist at 0xbfffc974, args: Locals at 0xbfffc974, Previous frame's sp is 0xbfffca14 I thought I could fix this in c-call.lisp, and this might be a good place to fix this, but my guess is that while this bit of code is correctly making 16-byte aligned stack frames, the stack pointer is misaligned before we even get here, perhaps quite early in the initialization. Now I'm wondering if the initial stack frame in call_into_lisp in ppc-assem.S is the culprit. But, clearly, I know very little about how lisp, C, etc... make and use their stack frames. I'd appreciate any suggestions like: lisp is going to make willy-nilly aligned stack frames and the c-calling code should be responsible for aligning it's stack frames to 16-byte boundaries, or: the lisp stack frame should be 16-byte and isn't. Anyway, hate to bug you guys with this, but I remain of the opinion that calling things like Carbon and QuickTime from lisp would be a good thing and that this is the latest roadblock to successfully being able to do so. Thanks, Cyrus |
From: Thiemo S. <th...@ne...> - 2005-10-09 20:16:51
|
Cyrus Harmon wrote: > Last week I, in a couple inappropriate places like my blog and an > email to Xophe instead of to sbcl-devel, brought up an issue I was > having with MacOS where when trying to call Carbon functions from > lisp, I was seeing some odd behavior. Gary Byers was kind enough to > point out that he had seen something similar with OpenMCL long ago > and that the stack needed to be aligned on 16-byte boundaries to keep > AltiVec happy. Gary syas: > > On Oct 5, 2005, at 4:25 PM, Gary Byers wrote: > >I don't know how far back John Wiseman's archives go, but lemonodor > >used to have (spring/summer of 2002 ?) screenshots of OpenMCL's Cocoa > >demo with psychedelic menu and text colors, so the problem looked > >familiar. If you have a G3 (which doesn't have AltiVec), you should > >find that your code runs without those artifacts there. > > I haven't tried the G3 thing, as I don't have one handy, but, indeed, > GDB suggests that by the time I'm calling Carbon functions like > StandardAlert, the stack is aligned on a 4 byte boundary, not a 16- > byte boundary: > > (gdb) info f > Stack level 0, frame at 0xbfffc974: > pc = 0x93319ed0 in StandardAlert; saved pc 0xc194 > called by frame at 0xbfffca14 > Arglist at 0xbfffc974, args: > Locals at 0xbfffc974, Previous frame's sp is 0xbfffca14 > > I thought I could fix this in c-call.lisp, and this might be a good > place to fix this, but my guess is that while this bit of code is > correctly making 16-byte aligned stack frames, the stack pointer is > misaligned before we even get here, perhaps quite early in the > initialization. Now I'm wondering if the initial stack frame in > call_into_lisp in ppc-assem.S is the culprit. But, clearly, I know > very little about how lisp, C, etc... make and use their stack > frames. I'd appreciate any suggestions like: lisp is going to make > willy-nilly aligned stack frames and the c-calling code should be > responsible for aligning it's stack frames to 16-byte boundaries, or: > the lisp stack frame should be 16-byte and isn't. I don't see a reason to have a single global rule for all the various stacks. A lisp-visible stack needs (at least) the lisp object alignment of 8 bytes, a C visible stack (I think that is reg_NFP) needs to have ABI conforming alignment. Making sure that reg_NFP stays at C alignment might be enough to solve the problem. Thiemo |
From: Christophe R. <cs...@ca...> - 2005-10-09 20:26:47
|
Cyrus Harmon <ch...@bo...> writes: > Now I'm wondering if the initial stack frame in > call_into_lisp in ppc-assem.S is the culprit. Well, couldn't you set a breakpoint in call_into_lisp before starting sbcl to find out? Something like $ gdb src/runtime/sbcl (gdb) break call_into_lisp (gdb) run --core output/sbcl.core Cheers, Christophe |
From: Cyrus H. <ch...@bo...> - 2005-10-09 22:11:52
|
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. Anyway, thanks for the attention to this, Cyrus On Oct 9, 2005, at 1:26 PM, Christophe Rhodes wrote: > Cyrus Harmon <ch...@bo...> writes: > > >> Now I'm wondering if the initial stack frame in >> call_into_lisp in ppc-assem.S is the culprit. >> > > Well, couldn't you set a breakpoint in call_into_lisp before starting > sbcl to find out? Something like > > $ gdb src/runtime/sbcl > (gdb) break call_into_lisp > (gdb) run --core output/sbcl.core > > 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 > |
From: Christophe R. <cs...@ca...> - 2005-10-10 06:29:08
|
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 |
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 > |
From: Cyrus H. <ch...@bo...> - 2005-10-11 03:42:57
|
Continuing my education about how the compiler works, how it generates code that calls out to C routines, etc..., I think I see how I can adjust nsp-tn so that the stack block created will be properly aligned. The problem I have is that I don't see how to unwind this properly. The alloc-number-stack-space and dealloc-number- stack-space vops get to now the size of the block to allocate, and one could calculate the amount of padding to make align properly, but then on the way back, we only know the size of the block, not the amount of the padding We could add another word for the previous nsp-tn so that we push the appropriate padding, the old nsp-tn, and then the new stack block and on the way out we would be able to get the size of the new stack block and then the address of the previous nsp-tn, which would take care of the padding for us. This adds 4 bytes (8 for 64-bit systems, but we don't support ppc-64 yet and probably never will, I imagine) for improperly aligned blocks and 16-bytes for previously aligned blocks. Seems worth it to be able to properly support the ABI, I guess. Does this sound reasonable? Thanks, 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 > |