Thanks!! Looks promising -- I'll run with it for awhile and see if I encounter any problems. (Note: only tried so far on Lion gcc(llvm))
On Aug 19, 2011, at 9:28 AM, Alexey Borzenkov wrote: > Jeff, try the one I commited this night in > https://bitbucket.org/snaury/greenlet but I haven't tested it much. > > On Aug 19, 2011 4:46 PM, "Jeff Senn" <[email protected]> wrote: > > Thanks, Alexey. > > > > I did try your suggestions -- unfortunately I still need the annoying line > > of nonsense code to avoid a crash... :-( > > I suppose it could be the registers/build issue -- unfortunately I don't > > have time to dig in the next several days, > > in the meantime, if you come up with a version of slp_switch for x86 that > > you believe is "build-option-proof" let me know and I'll be > > glad to try it... > > > > On Aug 18, 2011, at 2:17 PM, Alexey Borzenkov wrote: > > > >> Jeff, > >> > >> For what it's worth the situation with 32-bit is exactly the same as > >> 64-bit. Depending on configuration some registers are either cannot be > >> clobbered, or are not saved. You can see an example of compile switches in > >> my fork's bug report that can crash 32-bit greenlet on stock lion's Python. > >> > >> Regarding cst I already mentioned that it needs to be marked volatile due > >> to double return semantics of stack switches. There was the exact same > >> problem with static globals in greenlet, where slight changes in code > >> would make corruptions go away. > >> > >> On Aug 18, 2011 5:20 PM, "Jeff Senn" <[email protected]> wrote: > >> > Anselm - can you have a look and see what you think of Alexey's version? > >> > Compare with your earlier proposal? What is you current best version for > >> > me to test on OS-X > >> > (preferably w/o the darwin specific compile option which I can't tell if > >> > you > >> > thought was necessary or not...) > >> > > >> > FWIW: My problem with the 32-bit version does seem to have something to > >> > do > >> > with the llvm version of gcc on Lion... putting a useless (but not > >> > optimize-away-able) > >> > statement directly after the call to slp_switch that refers to cst and > >> > cstprev > >> > causes it to work again... so I suspect either some sort of "bug" > >> > in code generation -- or an optimization that breaks the stack > >> > switching... > >> > if this sounds familiar to anyone (before I have time to go rip apart > >> > and analyze > >> > the object code -- which will be awhile), please let me know... > >> > > >> > > >> > On Aug 17, 2011, at 6:09 PM, Alexey Borzenkov wrote: > >> > > >> >> On Fri, May 6, 2011 at 7:27 PM, Estevo <[email protected]> wrote: > >> >>> I got the following error trying to make release27-maint in a 64-bit > >> >>> > >> >>> gcc -pthread -c -fno-strict-aliasing -DSTACKLESS_FRHACK=0 -g -O2 > >> >>> -DNDEBUG -g > >> >>> -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include > >> >>> -I./Stackless > >> >>> -DPy_BUILD_CORE -fno-omit-frame-pointer -O2 -I. -o > >> >>> Stackless/core/slp_transfer.o > >> >>> ./Stackless/core/slp_transfer.c > >> >>> ./Stackless/core/slp_transfer.c: In function ‘slp_transfer’: > >> >>> ./Stackless/core/slp_transfer.c:153:1: error: bp cannot be used in asm > >> >>> here > >> >>> make: *** [Stackless/core/slp_transfer.o] Erro 1 > >> >> > >> >> While working on greenlet and fixing switch-related problems, I found > >> >> that I cornered myself into the same issue with gcc (as opposed to > >> >> llvm-gcc used on OS X Lion). It seems that for whatever reasons gcc > >> >> doesn't allow clobbering rbp when it's using it for referencing stack > >> >> frame. > >> >> > >> >> Coincidentally I managed to find a way to correctly save rbp (as well > >> >> as csr and cw), that works and compiles both with and without > >> >> -fomit-frame-pointers. In anyone is interested you can find my > >> >> slp_transfer for amd64 here: > >> >> > >> >> https://bitbucket.org/snaury/greenlet/src/5d37cde9474c/platform/switch_amd64_unix.h > >> >> > >> >> If anyone can verify it's 100% correct (though redundant), then you > >> >> can maybe use it in stackless too. > >> >> > >> >> _______________________________________________ > >> >> Stackless mailing list > >> >> [email protected] > >> >> http://www.stackless.com/mailman/listinfo/stackless > >> > > >> > > >> > _______________________________________________ > >> > Stackless mailing list > >> > [email protected] > >> > http://www.stackless.com/mailman/listinfo/stackless > >> _______________________________________________ > >> Stackless mailing list > >> [email protected] > >> http://www.stackless.com/mailman/listinfo/stackless > > > _______________________________________________ > Stackless mailing list > [email protected] > http://www.stackless.com/mailman/listinfo/stackless
_______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
