[Stackless] Problem building release27-maint in 64-bit linux.

Jeff Senn senn at maya.com
Fri Aug 19 14:43:51 CEST 2011


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" <senn at maya.com> 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 <euccastro at yahoo.com> 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
> >> Stackless at stackless.com
> >> http://www.stackless.com/mailman/listinfo/stackless
> > 
> > 
> > _______________________________________________
> > Stackless mailing list
> > Stackless at stackless.com
> > http://www.stackless.com/mailman/listinfo/stackless
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20110819/43f41fba/attachment.html>


More information about the Stackless mailing list