[llvm-dev] LLVM tail calling bug
罗勇刚(Yonggang Luo) via llvm-dev
llvm-dev at lists.llvm.org
Fri Jan 22 23:08:53 PST 2021
```
jerry-core/ecma/operations/ecma-proxy-object.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/jerry-core/ecma/operations/ecma-proxy-object.c
b/jerry-core/ecma/operations/ecma-proxy-object.c
index c5d299c6..77aed25c 100644
--- a/jerry-core/ecma/operations/ecma-proxy-object.c
+++ b/jerry-core/ecma/operations/ecma-proxy-object.c
@@ -1108,7 +1108,9 @@ ecma_proxy_object_get (ecma_object_t *obj_p, /**<
proxy object */
if (ecma_is_value_undefined (trap))
{
ecma_object_t *target_obj_p = ecma_get_object_from_value
(proxy_obj_p->target);
- return ecma_op_object_get_with_receiver (target_obj_p, prop_name_p,
receiver);
+ ecma_value_t value = ecma_op_object_get_with_receiver (target_obj_p,
prop_name_p, receiver);
+ fflush (stdout);
+ return value;
}
ecma_object_t *func_obj_p = ecma_get_object_from_value (trap);
```
In which condition, ecma_op_object_get_with_receiver tail calling will not
increase the stack-size?
I have a test-case that cause infinite loop, because that in normal
conition, it's expect to raise an stack-exceed error but
now with llvm-compiled release build binary, it's turn out to be infinite
loop because ecma_op_object_get_with_receiver
will not increase the stack size anymore, once
ecma_op_object_get_with_receiver getting called, it's returned to the
previous stack position。
Reproduced on OSX/Ubuntu 20.04
Stack-trace-base
```
jerry!ecma_proxy_object_get
(\Users\lygstate\work\typescript\jerryscript\jerry-core\ecma\operations\ecma-proxy-object.c:1111)
jerry!ecma_op_object_get_with_receiver
(\Users\lygstate\work\typescript\jerryscript\jerry-core\ecma\operations\ecma-objects.c:790)
jerry!ecma_op_object_get
(\Users\lygstate\work\typescript\jerryscript\jerry-core\ecma\operations\ecma-objects.c:763)
jerry!vm_op_get_value
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:114)
jerry!vm_loop
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:2799)
jerry!vm_execute
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:4939)
jerry!vm_run
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:5046)
jerry!vm_run_global
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:328)
jerry!jerry_run
(\Users\lygstate\work\typescript\jerryscript\jerry-core\api\jerry.c:671)
jerry!main
(\Users\lygstate\work\typescript\jerryscript\jerry-main\main-unix.c:156)
libdyld.dylib!start (Unknown Source:0)
libdyld.dylib!start (Unknown Source:0)
```
stack-trace-new, it's hope ecma_op_object_get_with_receiver to deeper, but
turn out to step-back.
```
jerry!ecma_op_object_get_with_receiver
(\Users\lygstate\work\typescript\jerryscript\jerry-core\ecma\operations\ecma-objects.c:784)
jerry!ecma_op_object_get
(\Users\lygstate\work\typescript\jerryscript\jerry-core\ecma\operations\ecma-objects.c:763)
jerry!vm_op_get_value
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:114)
jerry!vm_loop
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:2799)
jerry!vm_execute
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:4939)
jerry!vm_run
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:5046)
jerry!vm_run_global
(\Users\lygstate\work\typescript\jerryscript\jerry-core\vm\vm.c:328)
jerry!jerry_run
(\Users\lygstate\work\typescript\jerryscript\jerry-core\api\jerry.c:671)
jerry!main
(\Users\lygstate\work\typescript\jerryscript\jerry-main\main-unix.c:156)
libdyld.dylib!start (Unknown Source:0)
libdyld.dylib!start (Unknown Source:0)
```
Same clang , build it with debug flag, the issue gone. I am wonder if there
is a misoptimization here
The c code
https://gist.github.com/lygstate/b554e74a22353d50a24240128f875474
The full source tree
https://github.com/lygstate/jerryscript/tree/osx-clang-bug
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210122/69d14920/attachment.html>
More information about the llvm-dev
mailing list