Hi Armin,
Thank you for your reply.
> Try to translate with the option ``--withoutmod-cpyext``.
This option fixes the error, but now I encounter another error message (in
pypy_module_sys.c):
```
pypy_module_sys.c: In function 'pypy_g_setrecursionlimit':
pypy_module_sys.c:2890:9: warning: implicit declaration of function
'OP_GC_INCREASE_ROOT_STACK_DEPTH' [-Wimplicit-function-declaration]
2890 | OP_GC_INCREASE_ROOT_STACK_DEPTH(l_v498959, /*
nothing */);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pypy_module_sys.c:2890:65: error: expected expression before ')'
token
2890 | OP_GC_INCREASE_ROOT_STACK_DEPTH(l_v498959, /*
nothing */);
|
^
make: *** [Makefile:641: pypy_module_sys.o] Error 1
```
> Does the equivalent of
> `pypysrc\rpython\jit\backend\x86\test\test_zrpy_gc.py` pass on your
> backend? I guess it does, and so does a long-running
> `test_zll_stress_*.py`---but maybe try to run `test_zll_stress_*.py`
> for even longer, it can often eventually find bugs if they are really
> in the JIT backend.
Yes. test_zrpy_gc.py is passing.
I tried `test_zll_stress_*.py` and it passed too. Then, I increased
`total_iterations` to 10000 and decreased `pieces` to 1 and it still passed.
Just to be sure, is the following command correct?
```
python2.7 ./pytest.py rpython/jit/backend/test/test_zll_stress_0.py -s -v
```
If everything is correct, I feel that I have to debug this the hard way.
Let's see if I can find more leads or not. Thank you.
Regards,
Logan
On Fri, Feb 16, 2024 at 1:38 AM Armin Rigo <armin.r...@gmail.com> wrote:
> Hi Logan,
>
> On Fri, 16 Feb 2024 at 07:46, Logan Chien <tzuhsiang.ch...@gmail.com>
> wrote:
> > pypy_module_cpyext.c:125333:80: error: expected expression
> before ')' token
> > 125333 | OP_GC_RAWREFCOUNT_CREATE_LINK_PYOBJ(l_v451927,
> l_v451928, /* nothing */);
>
> Ah, I guess that we are missing a dependency. To compile with Boehm,
> you need to avoid this particular GC-related feature that is used by
> the cpyext module. Try to translate with the option
> ``--withoutmod-cpyext``.
>
> Does the equivalent of
> `pypysrc\rpython\jit\backend\x86\test\test_zrpy_gc.py` pass on your
> backend? I guess it does, and so does a long-running
> `test_zll_stress_*.py`---but maybe try to run `test_zll_stress_*.py`
> for even longer, it can often eventually find bugs if they are really
> in the JIT backend.
>
> If it doesn't help, then "congratulation", you are in the land of
> debugging the very rare crash with gdb. For this case, it's a matter
> of going earlier in time from the crash. If the crash is nicely
> reproductible, then you have a chance of doing this by setting correct
> breakpoints (hardware breakpoints on memory change, for example) and
> restarting the program and repeating. If it is too random, then that
> doesn't work; maybe look for what reverse debuggers are available
> nowadays. Last I looked, on x86-64, gdb had a built-in but useless
> one (only goes backward a little bit), but there was lldb which
> worked, and udb was still called undodb---but my guess would be that
> none of that works on RISC-V. If all else fails, I remember once
> hacking around to dump a huge amount of data (at least every single
> memory write into GC structures) (but that was outside the JIT;
> logging from generated assembly is made harder by the fact that the
> log calls must not cause the generated code to change apart from the
> calls). It would let me know exactly what happened---that was for one
> bug that took me 10 days of hard work, my personal best :-/
>
>
> A bientôt,
>
> Armin
>
_______________________________________________
pypy-dev mailing list -- pypy-dev@python.org
To unsubscribe send an email to pypy-dev-le...@python.org
https://mail.python.org/mailman3/lists/pypy-dev.python.org/
Member address: arch...@mail-archive.com
