Re: [webkit-dev] Stack Alignment error in LLINT
So I tracked this down to the way I have to build the debug library for QNX due to size issues. The issue goes away if I build the Release version. Just as a note, exceptions do not impact the stack alignment. I compiled a 32 bit Linux x86 version of Webkit, and it had no issues. Thanks for the help, Rodney On 07/27/2015 01:15 PM, Michael Saboff wrote: Rodney, The “align the stack” code for 32 bit platforms is found in Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm (http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm) beginning at line 218. There isn’t an if / elsif for Linux or QNX. This stack aligning code is at the top of the code that I think is generating your SIGTRAP. Unfortunately I don’t think that the offline assembler that “assembles” the LLINT code has an OS specific type for X86 QNX. You can try locally in your build adding “or X86” to the end of the “if X86_WIN” to see if that takes care of your issue. It would also be interesting to know if Linux build with exceptions has the problem as well. - Michael On Jul 27, 2015, at 8:50 AM, Rodney Dowdall wrote: Thanks for the response Michael. Where does the code that does the padding live? It may be that I need to add something in there. I can try changing what the stack alignment should be, but from what I understand the QNX OS should align to 16. Maybe it is the exceptions that are causing the problem. I could try building a 32 bit Linux build with exceptions on to see if I get the same problem. Regards, Rodney On 07/27/2015 11:24 AM, Michael Saboff wrote: Rodney, JavaScriptCore assumes that the stack is 16 byte aligned. This may be more restrictive than some OS / ABIs, but there is code to pad appropriately for some platforms. You didn’t say what OS you are running on, but maybe there needs to be a code added for your OS. Turning on C++ exceptions could be responsible, as that could be changing stack layout. I don’t know of any platform that turns on C++ exceptions, so you may be in uncharted waters. Your build is 2 months old, the current revision is 187434. You could also try a more recent build. - Michael On Jul 27, 2015, at 8:07 AM, Rodney Dowdall wrote: Hello I am seeing a SIGTRAP generated in the LLINT code when I try and load up a page. It happens as soon as the page tries to execute JavaScript. The target is an 32 bit x86 machine. The SIGTRAP appears to happen when it is checking the stack alignment. I have tried compiling the code with the gcc option -mstackrealign and without it. The SIGTRAP is generated in the same spot with or without the option. C++ exceptions are turned on (they have to be with this particular compiler. The compiler is gcc based). The version of Webkit that I am building from is 184845. Here is the assembly execution that causes the SIGTRAP: vmEntryToJavaScript: b9a80ef7: push %ebp b9a80ef8: mov %esp,%ebp b9a80efa: push %esi b9a80efb: push %edi b9a80efc: push %ebx b9a80efd: mov 0xc(%ebp),%ebx b9a80f00: mov 0x8(%ebp),%edi b9a80f03: mov %ebp,%esp b9a80f05: sub $0x20,%esp b9a80f08: mov %ebx,(%esp) b9a80f0b: mov 0x1498(%ebx),%edx b9a80f11: mov %edx,0x4(%esp) b9a80f15: mov 0x1494(%ebx),%edx b9a80f1b: mov %edx,0x8(%esp) b9a80f1f: mov 0x10(%ebp),%esi b9a80f22: mov 0x20(%esi),%edx b9a80f25: add $0x4,%edx b9a80f28: shl $0x3,%edx b9a80f2b: mov %esp,%eax b9a80f2d: sub %edx,%eax b9a80f2f: cmp 0x2384(%ebx),%eax b9a80f35: jae 0xb9a80f71 b9a80f71: mov %eax,%esp b9a80f73: mov $0x4,%eax b9a80f78: sub $0x1,%eax b9a80f7b: mov 0x4(%esi,%eax,8),%ecx b9a80f7f: mov %ecx,0xc(%esp,%eax,8) b9a80f83: mov (%esi,%eax,8),%ecx b9a80f86: mov %ecx,0x8(%esp,%eax,8) b9a80f8a: test %eax,%eax b9a80f8c: jne 0xb9a80f78 b9a80f9e: sub $0x1,%ecx b9a80fa1: movl $0xfffc,0x2c(%esp,%ecx,8) b9a80fa9: movl $0x0,0x28(%esp,%ecx,8) b9a80fb1: cmp %ecx,%edx b9a80fb3: jne 0xb9a80f9e b9a80fb5: mov 0x28(%esi),%eax b9a80fb8: test %edx,%edx b9a80fba: je 0xb9a80fd0 b9a80f78: sub $0x1,%eax b9a80f7b: mov 0x4(%esi,%eax,8),%ecx b9a80f7f: mov %ecx,0xc(%esp,%eax,8) b9a80f83: mov (%esi,%eax,8),%ecx b9a80f86: mov %ecx,0x8(%esp,%eax,8) b9a80f8a: test %eax,%eax b9a80f8c: jne 0xb9a80f78 b9a80f78: sub $0x1,%eax b9a80f7b: mov 0x4(%esi,%eax,8),%ecx b9a80f7f: mov %ecx,0xc(%esp,%eax,8) b9a80f83: mov (%esi,%eax,8),%ecx b9a80f86: mov %ecx,0x8(%esp,%eax,8) b9a80f8a: test %eax,%eax b9a80f8c: jne 0xb9a80f78 b9a80f78: sub $0x1,%eax b9a80f7b: mov 0x4(%esi,%eax,8),%ecx b9a80f7f: mov %ecx,0xc(%esp,%eax,8) b9a80f83: mov (%esi,%eax,8),%ecx b9a80f86: mov %ecx,0x8(%esp,%eax,8) b9a80f8a: test %eax,%eax b9a80f8c: jne 0xb9a80f78 b9a80f8e: mov 0x10(%esi),%edx b9a80f91: sub $0x1,%edx b9a80f94: mov 0x20(%esi),%ecx b9a80f97: sub $0x1,%ecx b9a80f9a: cmp %ecx,%edx b9a80f9c: je 0xb9a80fb5 b9a80fd0: mov %esp,0x1498(%ebx) b9a8
Re: [webkit-dev] Stack Alignment error in LLINT
Rodney, The “align the stack” code for 32 bit platforms is found in Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm (http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/llint/LowLevelInterpreter32_64.asm) beginning at line 218. There isn’t an if / elsif for Linux or QNX. This stack aligning code is at the top of the code that I think is generating your SIGTRAP. Unfortunately I don’t think that the offline assembler that “assembles” the LLINT code has an OS specific type for X86 QNX. You can try locally in your build adding “or X86” to the end of the “if X86_WIN” to see if that takes care of your issue. It would also be interesting to know if Linux build with exceptions has the problem as well. - Michael > On Jul 27, 2015, at 8:50 AM, Rodney Dowdall > wrote: > > Thanks for the response Michael. Where does the code that does the padding > live? It may be that I need to add something in there. I can try changing > what the stack alignment should be, but from what I understand the QNX OS > should align to 16. Maybe it is the exceptions that are causing the problem. > I could try building a 32 bit Linux build with exceptions on to see if I get > the same problem. > > Regards, > Rodney > > On 07/27/2015 11:24 AM, Michael Saboff wrote: >> Rodney, >> >> JavaScriptCore assumes that the stack is 16 byte aligned. This may be more >> restrictive than some OS / ABIs, but there is code to pad appropriately for >> some platforms. You didn’t say what OS you are running on, but maybe there >> needs to be a code added for your OS. Turning on C++ exceptions could be >> responsible, as that could be changing stack layout. I don’t know of any >> platform that turns on C++ exceptions, so you may be in uncharted waters. >> >> Your build is 2 months old, the current revision is 187434. You could also >> try a more recent build. >> >> - Michael >> >>> On Jul 27, 2015, at 8:07 AM, Rodney Dowdall >>> wrote: >>> >>> Hello >>> >>> I am seeing a SIGTRAP generated in the LLINT code when I try and load up a >>> page. It happens as soon as the page tries to execute JavaScript. The >>> target is an 32 bit x86 machine. The SIGTRAP appears to happen when it is >>> checking the stack alignment. I have tried compiling the code with the gcc >>> option -mstackrealign and without it. The SIGTRAP is generated in the same >>> spot with or without the option. C++ exceptions are turned on (they have >>> to be with this particular compiler. The compiler is gcc based). The >>> version of Webkit that I am building from is 184845. >>> >>> >>> Here is the assembly execution that causes the SIGTRAP: >>> >>> vmEntryToJavaScript: >>> b9a80ef7: push %ebp >>> b9a80ef8: mov %esp,%ebp >>> b9a80efa: push %esi >>> b9a80efb: push %edi >>> b9a80efc: push %ebx >>> b9a80efd: mov 0xc(%ebp),%ebx >>> b9a80f00: mov 0x8(%ebp),%edi >>> b9a80f03: mov %ebp,%esp >>> b9a80f05: sub $0x20,%esp >>> b9a80f08: mov %ebx,(%esp) >>> b9a80f0b: mov 0x1498(%ebx),%edx >>> b9a80f11: mov %edx,0x4(%esp) >>> b9a80f15: mov 0x1494(%ebx),%edx >>> b9a80f1b: mov %edx,0x8(%esp) >>> b9a80f1f: mov 0x10(%ebp),%esi >>> b9a80f22: mov 0x20(%esi),%edx >>> b9a80f25: add $0x4,%edx >>> b9a80f28: shl $0x3,%edx >>> b9a80f2b: mov %esp,%eax >>> b9a80f2d: sub %edx,%eax >>> b9a80f2f: cmp 0x2384(%ebx),%eax >>> b9a80f35: jae 0xb9a80f71 >>> >>> b9a80f71: mov %eax,%esp >>> b9a80f73: mov $0x4,%eax >>> b9a80f78: sub $0x1,%eax >>> b9a80f7b: mov 0x4(%esi,%eax,8),%ecx >>> b9a80f7f: mov %ecx,0xc(%esp,%eax,8) >>> b9a80f83: mov (%esi,%eax,8),%ecx >>> b9a80f86: mov %ecx,0x8(%esp,%eax,8) >>> b9a80f8a: test %eax,%eax >>> b9a80f8c: jne 0xb9a80f78 >>> >>> b9a80f9e: sub $0x1,%ecx >>> b9a80fa1: movl $0xfffc,0x2c(%esp,%ecx,8) >>> b9a80fa9: movl $0x0,0x28(%esp,%ecx,8) >>> b9a80fb1: cmp %ecx,%edx >>> b9a80fb3: jne 0xb9a80f9e >>> b9a80fb5: mov 0x28(%esi),%eax >>> b9a80fb8: test %edx,%edx >>> b9a80fba: je 0xb9a80fd0 >>> >>> b9a80f78: sub $0x1,%eax >>> b9a80f7b: mov 0x4(%esi,%eax,8),%ecx >>> b9a80f7f: mov %ecx,0xc(%esp,%eax,8) >>> b9a80f83: mov (%esi,%eax,8),%ecx >>> b9a80f86: mov %ecx,0x8(%esp,%eax,8) >>> b9a80f8a: test %eax,%eax >>> b9a80f8c: jne 0xb9a80f78 >>> >>> b9a80f78: sub $0x1,%eax >>> b9a80f7b: mov 0x4(%esi,%eax,8),%ecx >>> b9a80f7f: mov %ecx,0xc(%esp,%eax,8) >>> b9a80f83: mov (%esi,%eax,8),%ecx >>> b9a80f86: mov %ecx,0x8(%esp,%eax,8) >>> b9a80f8a: test %eax,%eax >>> b9a80f8c: jne 0xb9a80f78 >>> >>> b9a80f78: sub $0x1,%eax >>> b9a80f7b: mov 0x4(%esi,%eax,8),%ecx >>> b9a80f7f: mov %ecx,0xc(%esp,%eax,8) >>> b9a80f83: mov (%esi,%eax,8),%ecx >>> b9a80f86: mov %ecx,0x8(%esp,%eax,8) >>> b9a80f8a: test %eax,%eax >>> b9a80f8c: jne 0xb9a80f78 >>> b9a80f8e: mov 0x10(%esi),%edx >>> b9a80f91: sub $0x1,%edx >>> b9a80f94: mov 0x20(%esi),%ecx >>> b9a80f97: sub $0x1,%ecx >>> b9a80f9a: cmp %ecx,%edx >>> b9a80f9c
Re: [webkit-dev] Stack Alignment error in LLINT
We generally assume that calls into JavaScriptCore are made on an aligned stack. So, to my knowledge, our code does not usually do dynamic stack realignment. You should check the vmEntryToJavascript thunk - which gets called when you make a call into JS from native code - to see if it does dynamic realignment. You could add dynamic realignment code there if it isn't there already. -Filip > On Jul 27, 2015, at 8:50 AM, Rodney Dowdall > wrote: > > Thanks for the response Michael. Where does the code that does the padding > live? It may be that I need to add something in there. I can try changing > what the stack alignment should be, but from what I understand the QNX OS > should align to 16. Maybe it is the exceptions that are causing the problem. > I could try building a 32 bit Linux build with exceptions on to see if I get > the same problem. > > Regards, > Rodney > >> On 07/27/2015 11:24 AM, Michael Saboff wrote: >> Rodney, >> >> JavaScriptCore assumes that the stack is 16 byte aligned. This may be more >> restrictive than some OS / ABIs, but there is code to pad appropriately for >> some platforms. You didn’t say what OS you are running on, but maybe there >> needs to be a code added for your OS. Turning on C++ exceptions could be >> responsible, as that could be changing stack layout. I don’t know of any >> platform that turns on C++ exceptions, so you may be in uncharted waters. >> >> Your build is 2 months old, the current revision is 187434. You could also >> try a more recent build. >> >> - Michael >> >>> On Jul 27, 2015, at 8:07 AM, Rodney Dowdall >>> wrote: >>> >>> Hello >>> >>> I am seeing a SIGTRAP generated in the LLINT code when I try and load up a >>> page. It happens as soon as the page tries to execute JavaScript. The >>> target is an 32 bit x86 machine. The SIGTRAP appears to happen when it is >>> checking the stack alignment. I have tried compiling the code with the gcc >>> option -mstackrealign and without it. The SIGTRAP is generated in the same >>> spot with or without the option. C++ exceptions are turned on (they have >>> to be with this particular compiler. The compiler is gcc based). The >>> version of Webkit that I am building from is 184845. >>> >>> >>> Here is the assembly execution that causes the SIGTRAP: >>> >>> vmEntryToJavaScript: >>> b9a80ef7: push %ebp >>> b9a80ef8: mov %esp,%ebp >>> b9a80efa: push %esi >>> b9a80efb: push %edi >>> b9a80efc: push %ebx >>> b9a80efd: mov 0xc(%ebp),%ebx >>> b9a80f00: mov 0x8(%ebp),%edi >>> b9a80f03: mov %ebp,%esp >>> b9a80f05: sub $0x20,%esp >>> b9a80f08: mov %ebx,(%esp) >>> b9a80f0b: mov 0x1498(%ebx),%edx >>> b9a80f11: mov %edx,0x4(%esp) >>> b9a80f15: mov 0x1494(%ebx),%edx >>> b9a80f1b: mov %edx,0x8(%esp) >>> b9a80f1f: mov 0x10(%ebp),%esi >>> b9a80f22: mov 0x20(%esi),%edx >>> b9a80f25: add $0x4,%edx >>> b9a80f28: shl $0x3,%edx >>> b9a80f2b: mov %esp,%eax >>> b9a80f2d: sub %edx,%eax >>> b9a80f2f: cmp 0x2384(%ebx),%eax >>> b9a80f35: jae 0xb9a80f71 >>> >>> b9a80f71: mov %eax,%esp >>> b9a80f73: mov $0x4,%eax >>> b9a80f78: sub $0x1,%eax >>> b9a80f7b: mov 0x4(%esi,%eax,8),%ecx >>> b9a80f7f: mov %ecx,0xc(%esp,%eax,8) >>> b9a80f83: mov (%esi,%eax,8),%ecx >>> b9a80f86: mov %ecx,0x8(%esp,%eax,8) >>> b9a80f8a: test %eax,%eax >>> b9a80f8c: jne 0xb9a80f78 >>> >>> b9a80f9e: sub $0x1,%ecx >>> b9a80fa1: movl $0xfffc,0x2c(%esp,%ecx,8) >>> b9a80fa9: movl $0x0,0x28(%esp,%ecx,8) >>> b9a80fb1: cmp %ecx,%edx >>> b9a80fb3: jne 0xb9a80f9e >>> b9a80fb5: mov 0x28(%esi),%eax >>> b9a80fb8: test %edx,%edx >>> b9a80fba: je 0xb9a80fd0 >>> >>> b9a80f78: sub $0x1,%eax >>> b9a80f7b: mov 0x4(%esi,%eax,8),%ecx >>> b9a80f7f: mov %ecx,0xc(%esp,%eax,8) >>> b9a80f83: mov (%esi,%eax,8),%ecx >>> b9a80f86: mov %ecx,0x8(%esp,%eax,8) >>> b9a80f8a: test %eax,%eax >>> b9a80f8c: jne 0xb9a80f78 >>> >>> b9a80f78: sub $0x1,%eax >>> b9a80f7b: mov 0x4(%esi,%eax,8),%ecx >>> b9a80f7f: mov %ecx,0xc(%esp,%eax,8) >>> b9a80f83: mov (%esi,%eax,8),%ecx >>> b9a80f86: mov %ecx,0x8(%esp,%eax,8) >>> b9a80f8a: test %eax,%eax >>> b9a80f8c: jne 0xb9a80f78 >>> >>> b9a80f78: sub $0x1,%eax >>> b9a80f7b: mov 0x4(%esi,%eax,8),%ecx >>> b9a80f7f: mov %ecx,0xc(%esp,%eax,8) >>> b9a80f83: mov (%esi,%eax,8),%ecx >>> b9a80f86: mov %ecx,0x8(%esp,%eax,8) >>> b9a80f8a: test %eax,%eax >>> b9a80f8c: jne 0xb9a80f78 >>> b9a80f8e: mov 0x10(%esi),%edx >>> b9a80f91: sub $0x1,%edx >>> b9a80f94: mov 0x20(%esi),%ecx >>> b9a80f97: sub $0x1,%ecx >>> b9a80f9a: cmp %ecx,%edx >>> b9a80f9c: je 0xb9a80fb5 >>> >>> b9a80fd0: mov %esp,0x1498(%ebx) >>> b9a80fd6: mov %ebp,0x1494(%ebx) >>> b9a80fdc: add $0x8,%esp >>> b9a80fdf: mov %esp,%ecx >>> b9a80fe1: and $0xf,%ecx >>> b9a80fe4: test %ecx,%ecx >>> b9a80fe6: je 0xb9a80fee >>> b9a80fe8: mov $0xbad0dc02,%ecx >>> b9a80fed: int3 >>> >>> So using the LLintAssembly.
Re: [webkit-dev] Stack Alignment error in LLINT
Thanks for the response Michael. Where does the code that does the padding live? It may be that I need to add something in there. I can try changing what the stack alignment should be, but from what I understand the QNX OS should align to 16. Maybe it is the exceptions that are causing the problem. I could try building a 32 bit Linux build with exceptions on to see if I get the same problem. Regards, Rodney On 07/27/2015 11:24 AM, Michael Saboff wrote: Rodney, JavaScriptCore assumes that the stack is 16 byte aligned. This may be more restrictive than some OS / ABIs, but there is code to pad appropriately for some platforms. You didn’t say what OS you are running on, but maybe there needs to be a code added for your OS. Turning on C++ exceptions could be responsible, as that could be changing stack layout. I don’t know of any platform that turns on C++ exceptions, so you may be in uncharted waters. Your build is 2 months old, the current revision is 187434. You could also try a more recent build. - Michael On Jul 27, 2015, at 8:07 AM, Rodney Dowdall wrote: Hello I am seeing a SIGTRAP generated in the LLINT code when I try and load up a page. It happens as soon as the page tries to execute JavaScript. The target is an 32 bit x86 machine. The SIGTRAP appears to happen when it is checking the stack alignment. I have tried compiling the code with the gcc option -mstackrealign and without it. The SIGTRAP is generated in the same spot with or without the option. C++ exceptions are turned on (they have to be with this particular compiler. The compiler is gcc based). The version of Webkit that I am building from is 184845. Here is the assembly execution that causes the SIGTRAP: vmEntryToJavaScript: b9a80ef7: push %ebp b9a80ef8: mov %esp,%ebp b9a80efa: push %esi b9a80efb: push %edi b9a80efc: push %ebx b9a80efd: mov 0xc(%ebp),%ebx b9a80f00: mov 0x8(%ebp),%edi b9a80f03: mov %ebp,%esp b9a80f05: sub $0x20,%esp b9a80f08: mov %ebx,(%esp) b9a80f0b: mov 0x1498(%ebx),%edx b9a80f11: mov %edx,0x4(%esp) b9a80f15: mov 0x1494(%ebx),%edx b9a80f1b: mov %edx,0x8(%esp) b9a80f1f: mov 0x10(%ebp),%esi b9a80f22: mov 0x20(%esi),%edx b9a80f25: add $0x4,%edx b9a80f28: shl $0x3,%edx b9a80f2b: mov %esp,%eax b9a80f2d: sub %edx,%eax b9a80f2f: cmp 0x2384(%ebx),%eax b9a80f35: jae 0xb9a80f71 b9a80f71: mov %eax,%esp b9a80f73: mov $0x4,%eax b9a80f78: sub $0x1,%eax b9a80f7b: mov 0x4(%esi,%eax,8),%ecx b9a80f7f: mov %ecx,0xc(%esp,%eax,8) b9a80f83: mov (%esi,%eax,8),%ecx b9a80f86: mov %ecx,0x8(%esp,%eax,8) b9a80f8a: test %eax,%eax b9a80f8c: jne 0xb9a80f78 b9a80f9e: sub $0x1,%ecx b9a80fa1: movl $0xfffc,0x2c(%esp,%ecx,8) b9a80fa9: movl $0x0,0x28(%esp,%ecx,8) b9a80fb1: cmp %ecx,%edx b9a80fb3: jne 0xb9a80f9e b9a80fb5: mov 0x28(%esi),%eax b9a80fb8: test %edx,%edx b9a80fba: je 0xb9a80fd0 b9a80f78: sub $0x1,%eax b9a80f7b: mov 0x4(%esi,%eax,8),%ecx b9a80f7f: mov %ecx,0xc(%esp,%eax,8) b9a80f83: mov (%esi,%eax,8),%ecx b9a80f86: mov %ecx,0x8(%esp,%eax,8) b9a80f8a: test %eax,%eax b9a80f8c: jne 0xb9a80f78 b9a80f78: sub $0x1,%eax b9a80f7b: mov 0x4(%esi,%eax,8),%ecx b9a80f7f: mov %ecx,0xc(%esp,%eax,8) b9a80f83: mov (%esi,%eax,8),%ecx b9a80f86: mov %ecx,0x8(%esp,%eax,8) b9a80f8a: test %eax,%eax b9a80f8c: jne 0xb9a80f78 b9a80f78: sub $0x1,%eax b9a80f7b: mov 0x4(%esi,%eax,8),%ecx b9a80f7f: mov %ecx,0xc(%esp,%eax,8) b9a80f83: mov (%esi,%eax,8),%ecx b9a80f86: mov %ecx,0x8(%esp,%eax,8) b9a80f8a: test %eax,%eax b9a80f8c: jne 0xb9a80f78 b9a80f8e: mov 0x10(%esi),%edx b9a80f91: sub $0x1,%edx b9a80f94: mov 0x20(%esi),%ecx b9a80f97: sub $0x1,%ecx b9a80f9a: cmp %ecx,%edx b9a80f9c: je 0xb9a80fb5 b9a80fd0: mov %esp,0x1498(%ebx) b9a80fd6: mov %ebp,0x1494(%ebx) b9a80fdc: add $0x8,%esp b9a80fdf: mov %esp,%ecx b9a80fe1: and $0xf,%ecx b9a80fe4: test %ecx,%ecx b9a80fe6: je 0xb9a80fee b9a80fe8: mov $0xbad0dc02,%ecx b9a80fed: int3 So using the LLintAssembly.h I tracked this too: "\tjz " LOCAL_LABEL_STRING(_offlineasm_doVMEntry__makeCall__checkStackPointerAlignment__stackPointerOkay Which leads me to believe that the alignment on my stack is wrong. The value of esp is 0x7db9284. The value of ecx after the and is 4, so that looks right. I don't have a lot of experience with the LLINT, so I was wondering if there was a specific place I should start to look to see why this error is beign generated. Thanks, Rodney ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Stack Alignment error in LLINT
Rodney, JavaScriptCore assumes that the stack is 16 byte aligned. This may be more restrictive than some OS / ABIs, but there is code to pad appropriately for some platforms. You didn’t say what OS you are running on, but maybe there needs to be a code added for your OS. Turning on C++ exceptions could be responsible, as that could be changing stack layout. I don’t know of any platform that turns on C++ exceptions, so you may be in uncharted waters. Your build is 2 months old, the current revision is 187434. You could also try a more recent build. - Michael > On Jul 27, 2015, at 8:07 AM, Rodney Dowdall > wrote: > > Hello > > I am seeing a SIGTRAP generated in the LLINT code when I try and load up a > page. It happens as soon as the page tries to execute JavaScript. The > target is an 32 bit x86 machine. The SIGTRAP appears to happen when it is > checking the stack alignment. I have tried compiling the code with the gcc > option -mstackrealign and without it. The SIGTRAP is generated in the same > spot with or without the option. C++ exceptions are turned on (they have to > be with this particular compiler. The compiler is gcc based). The version > of Webkit that I am building from is 184845. > > > Here is the assembly execution that causes the SIGTRAP: > > vmEntryToJavaScript: > b9a80ef7: push %ebp > b9a80ef8: mov %esp,%ebp > b9a80efa: push %esi > b9a80efb: push %edi > b9a80efc: push %ebx > b9a80efd: mov 0xc(%ebp),%ebx > b9a80f00: mov 0x8(%ebp),%edi > b9a80f03: mov %ebp,%esp > b9a80f05: sub $0x20,%esp > b9a80f08: mov %ebx,(%esp) > b9a80f0b: mov 0x1498(%ebx),%edx > b9a80f11: mov %edx,0x4(%esp) > b9a80f15: mov 0x1494(%ebx),%edx > b9a80f1b: mov %edx,0x8(%esp) > b9a80f1f: mov 0x10(%ebp),%esi > b9a80f22: mov 0x20(%esi),%edx > b9a80f25: add $0x4,%edx > b9a80f28: shl $0x3,%edx > b9a80f2b: mov %esp,%eax > b9a80f2d: sub %edx,%eax > b9a80f2f: cmp 0x2384(%ebx),%eax > b9a80f35: jae 0xb9a80f71 > > b9a80f71: mov %eax,%esp > b9a80f73: mov $0x4,%eax > b9a80f78: sub $0x1,%eax > b9a80f7b: mov 0x4(%esi,%eax,8),%ecx > b9a80f7f: mov %ecx,0xc(%esp,%eax,8) > b9a80f83: mov (%esi,%eax,8),%ecx > b9a80f86: mov %ecx,0x8(%esp,%eax,8) > b9a80f8a: test %eax,%eax > b9a80f8c: jne 0xb9a80f78 > > b9a80f9e: sub $0x1,%ecx > b9a80fa1: movl $0xfffc,0x2c(%esp,%ecx,8) > b9a80fa9: movl $0x0,0x28(%esp,%ecx,8) > b9a80fb1: cmp %ecx,%edx > b9a80fb3: jne 0xb9a80f9e > b9a80fb5: mov 0x28(%esi),%eax > b9a80fb8: test %edx,%edx > b9a80fba: je 0xb9a80fd0 > > b9a80f78: sub $0x1,%eax > b9a80f7b: mov 0x4(%esi,%eax,8),%ecx > b9a80f7f: mov %ecx,0xc(%esp,%eax,8) > b9a80f83: mov (%esi,%eax,8),%ecx > b9a80f86: mov %ecx,0x8(%esp,%eax,8) > b9a80f8a: test %eax,%eax > b9a80f8c: jne 0xb9a80f78 > > b9a80f78: sub $0x1,%eax > b9a80f7b: mov 0x4(%esi,%eax,8),%ecx > b9a80f7f: mov %ecx,0xc(%esp,%eax,8) > b9a80f83: mov (%esi,%eax,8),%ecx > b9a80f86: mov %ecx,0x8(%esp,%eax,8) > b9a80f8a: test %eax,%eax > b9a80f8c: jne 0xb9a80f78 > > b9a80f78: sub $0x1,%eax > b9a80f7b: mov 0x4(%esi,%eax,8),%ecx > b9a80f7f: mov %ecx,0xc(%esp,%eax,8) > b9a80f83: mov (%esi,%eax,8),%ecx > b9a80f86: mov %ecx,0x8(%esp,%eax,8) > b9a80f8a: test %eax,%eax > b9a80f8c: jne 0xb9a80f78 > b9a80f8e: mov 0x10(%esi),%edx > b9a80f91: sub $0x1,%edx > b9a80f94: mov 0x20(%esi),%ecx > b9a80f97: sub $0x1,%ecx > b9a80f9a: cmp %ecx,%edx > b9a80f9c: je 0xb9a80fb5 > > b9a80fd0: mov %esp,0x1498(%ebx) > b9a80fd6: mov %ebp,0x1494(%ebx) > b9a80fdc: add $0x8,%esp > b9a80fdf: mov %esp,%ecx > b9a80fe1: and $0xf,%ecx > b9a80fe4: test %ecx,%ecx > b9a80fe6: je 0xb9a80fee > b9a80fe8: mov $0xbad0dc02,%ecx > b9a80fed: int3 > > So using the LLintAssembly.h I tracked this too: > >"\tjz " > LOCAL_LABEL_STRING(_offlineasm_doVMEntry__makeCall__checkStackPointerAlignment__stackPointerOkay > > Which leads me to believe that the alignment on my stack is wrong. The value > of esp is 0x7db9284. The value of ecx after the and is 4, so that looks > right. > > I don't have a lot of experience with the LLINT, so I was wondering if there > was a specific place I should start to look to see why this error is beign > generated. > > Thanks, > Rodney > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Stack Alignment error in LLINT
Hello I am seeing a SIGTRAP generated in the LLINT code when I try and load up a page. It happens as soon as the page tries to execute JavaScript. The target is an 32 bit x86 machine. The SIGTRAP appears to happen when it is checking the stack alignment. I have tried compiling the code with the gcc option -mstackrealign and without it. The SIGTRAP is generated in the same spot with or without the option. C++ exceptions are turned on (they have to be with this particular compiler. The compiler is gcc based). The version of Webkit that I am building from is 184845. Here is the assembly execution that causes the SIGTRAP: vmEntryToJavaScript: b9a80ef7: push %ebp b9a80ef8: mov %esp,%ebp b9a80efa: push %esi b9a80efb: push %edi b9a80efc: push %ebx b9a80efd: mov 0xc(%ebp),%ebx b9a80f00: mov 0x8(%ebp),%edi b9a80f03: mov %ebp,%esp b9a80f05: sub $0x20,%esp b9a80f08: mov %ebx,(%esp) b9a80f0b: mov 0x1498(%ebx),%edx b9a80f11: mov %edx,0x4(%esp) b9a80f15: mov 0x1494(%ebx),%edx b9a80f1b: mov %edx,0x8(%esp) b9a80f1f: mov 0x10(%ebp),%esi b9a80f22: mov 0x20(%esi),%edx b9a80f25: add $0x4,%edx b9a80f28: shl $0x3,%edx b9a80f2b: mov %esp,%eax b9a80f2d: sub %edx,%eax b9a80f2f: cmp 0x2384(%ebx),%eax b9a80f35: jae 0xb9a80f71 b9a80f71: mov %eax,%esp b9a80f73: mov $0x4,%eax b9a80f78: sub $0x1,%eax b9a80f7b: mov 0x4(%esi,%eax,8),%ecx b9a80f7f: mov %ecx,0xc(%esp,%eax,8) b9a80f83: mov (%esi,%eax,8),%ecx b9a80f86: mov %ecx,0x8(%esp,%eax,8) b9a80f8a: test %eax,%eax b9a80f8c: jne 0xb9a80f78 b9a80f9e: sub $0x1,%ecx b9a80fa1: movl $0xfffc,0x2c(%esp,%ecx,8) b9a80fa9: movl $0x0,0x28(%esp,%ecx,8) b9a80fb1: cmp %ecx,%edx b9a80fb3: jne 0xb9a80f9e b9a80fb5: mov 0x28(%esi),%eax b9a80fb8: test %edx,%edx b9a80fba: je 0xb9a80fd0 b9a80f78: sub $0x1,%eax b9a80f7b: mov 0x4(%esi,%eax,8),%ecx b9a80f7f: mov %ecx,0xc(%esp,%eax,8) b9a80f83: mov (%esi,%eax,8),%ecx b9a80f86: mov %ecx,0x8(%esp,%eax,8) b9a80f8a: test %eax,%eax b9a80f8c: jne 0xb9a80f78 b9a80f78: sub $0x1,%eax b9a80f7b: mov 0x4(%esi,%eax,8),%ecx b9a80f7f: mov %ecx,0xc(%esp,%eax,8) b9a80f83: mov (%esi,%eax,8),%ecx b9a80f86: mov %ecx,0x8(%esp,%eax,8) b9a80f8a: test %eax,%eax b9a80f8c: jne 0xb9a80f78 b9a80f78: sub $0x1,%eax b9a80f7b: mov 0x4(%esi,%eax,8),%ecx b9a80f7f: mov %ecx,0xc(%esp,%eax,8) b9a80f83: mov (%esi,%eax,8),%ecx b9a80f86: mov %ecx,0x8(%esp,%eax,8) b9a80f8a: test %eax,%eax b9a80f8c: jne 0xb9a80f78 b9a80f8e: mov 0x10(%esi),%edx b9a80f91: sub $0x1,%edx b9a80f94: mov 0x20(%esi),%ecx b9a80f97: sub $0x1,%ecx b9a80f9a: cmp %ecx,%edx b9a80f9c: je 0xb9a80fb5 b9a80fd0: mov %esp,0x1498(%ebx) b9a80fd6: mov %ebp,0x1494(%ebx) b9a80fdc: add $0x8,%esp b9a80fdf: mov %esp,%ecx b9a80fe1: and $0xf,%ecx b9a80fe4: test %ecx,%ecx b9a80fe6: je 0xb9a80fee b9a80fe8: mov $0xbad0dc02,%ecx b9a80fed: int3 So using the LLintAssembly.h I tracked this too: "\tjz " LOCAL_LABEL_STRING(_offlineasm_doVMEntry__makeCall__checkStackPointerAlignment__stackPointerOkay Which leads me to believe that the alignment on my stack is wrong. The value of esp is 0x7db9284. The value of ecx after the and is 4, so that looks right. I don't have a lot of experience with the LLINT, so I was wondering if there was a specific place I should start to look to see why this error is beign generated. Thanks, Rodney ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
