Summary: | dev-python/pypy fails to build with gcc-4.9 - AssertionError: unrecognized function prologue - only supports push %ebp; movl %esp, %ebp | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Justin Lecher (RETIRED) <jlec> |
Component: | Current packages | Assignee: | Alice Ferrazzi <alicef> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | jana, jason, O01eg, python |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bitbucket.org/pypy/pypy/issues/1764 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 495124 | ||
Attachments: | pypy-2.3.1-r1:20140914-143659.log.xz |
Description
Justin Lecher (RETIRED)
2014-09-14 16:06:15 UTC
Created attachment 384728 [details]
pypy-2.3.1-r1:20140914-143659.log.xz
build.og
I would suggest looking for a bug report upstream, and creating one if none exists already. Oh, I see Justin has already done so. Nevermind. I am trying to get the patch backported. I have no luck, but it seems they plan to release 2.3.2 which should have all that fixed. Hi, just wondering if this is because -march=native enables 256 bit AVX. Because if that happens, gcc 4.9 will happily add code in the function prologue to realign the stack to 256 bits (default for amd64 is 16 byte, i.e. 128 bits) and that function prologue breaks the gcroot analyzer. A temporary workaround that helper be was to add -mprefer-avx128 to the gcc flags for pypy. (less invasive than deactivating all architecture specific optimizations) I just tested - pypy 2.4.0 seems to compile fine with all compiler flags, so this issue seems to have been resolved. (hint: pypy 2.4.0 has been release - works with the same ebuild out of the box for me) Oh no... seems I was impatient. [platform:Error] AssertionError: unrecognized function prologue - only supports push %ebp; movl %esp, %ebp Still with 2.4.0. Where did you find the patch you are talking about? (In reply to Jana Saout from comment #7) > Still with 2.4.0. Where did you find the patch you are talking about? https://mail.python.org/pipermail/pypy-issue/2014-May/005127.html and other commits if you are searching for problems with pypy and gcc-4.9. Ah, I believe that was a different bug and was already fixed in 2.3.1. Is it possible to get the assembler source file that causes the problem? They are autogenerated during the translation process and should be found in /var/tmp/portage/dev-python/pypy-2.4.0/temp/usession-release-2.4.0-current/testing_1 (the ones with the .s ending - one of the function realigns the stack using an "and ...%rsp" if this is the same issue I am seeing. Something which isn't supported or handled if I am correctly informed) gcc 4.8 doesn't attempt the stack alignment but uses potential unaligned 256-bit AVX registers on the stack instead. Here it is: leto:/var/tmp/portage/dev-python/pypy-2.4.0/temp/usession-release-2.4.0-current/testing_1 # grep 'and.*rsp' implement.s andq $-32, %rsp (in my case implement.s, you can find it in that directory just afther the translation fails) The problematic function prologue looks like this: .LFE166: .size pypy_g_dispatcher_2, .-pypy_g_dispatcher_2 .section .text.unlikely .LCOLDE32: .text .LHOTE32: .section .text.unlikely .LCOLDB33: .text .LHOTB33: .p2align 4,,15 .globl pypy_g_ll_join_chars_look_inside_iff__Signed_arrayPtr_P .type pypy_g_ll_join_chars_look_inside_iff__Signed_arrayPtr_P, @function pypy_g_ll_join_chars_look_inside_iff__Signed_arrayPtr_P: .LFB167: .cfi_startproc leaq 8(%rsp), %r10 .cfi_def_cfa 10, 0 andq $-32, %rsp pushq -8(%r10) pushq %rbp .cfi_escape 0x10,0x6,0x2,0x76,0 movq %rsp, %rbp pushq %r12 .cfi_escape 0x10,0xc,0x2,0x76,0x78 Same with pypy-2.4.0 *** Bug 568698 has been marked as a duplicate of this bug. *** reported fixed upstream 2014-05-12, probably in pypy 4 or greater, please test. I'm not sure this is the same bug as the two other bug reports. I attached build logs to both the pypy and pypy3 bugs for anyone curious. I provided links to the corresponding pypy bug reports as well. I submitted a pull request that resolves this on github (https://github.com/gentoo/gentoo/pull/534), however the pull request wasn't accepted. For anyone else experiencing this issue, the simplest solution is most likely using USE=shadowstack, which may or may not perform as well as asmgcroot if GC performance is an issue (http://pypy.readthedocs.org/en/latest/config/translation.gcrootfinder.html). |