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
