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

[Alexey Borzenkov]

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" <senn at maya.com> 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" <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/9e890ae3/attachment.html>