Re: Contribute a RISC-V 64 JIT backend
Logan Chien <[email protected]> Sun, 18 Feb 2024 20:02:42 -0800
| Newsgroups | gmane.comp.python.pypy |
|---|---|
| Message-ID | <CALQyFuAEhvqts7_S+JaXcC9EJqCrpkuBULTchY+=6rRXq-sTyg@mail.gmail.com> |
--===============5654457552565333750==
Content-Type: multipart/alternative; boundary="0000000000000143f50611b42bbd"
--0000000000000143f50611b42bbd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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=E2=80=AFAM Armin Rigo <[email protected]> w=
rote:
> Hi Logan,
>
> On Fri, 16 Feb 2024 at 07:46, Logan Chien <[email protected]>
> 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=C3=B4t,
>
> Armin
>
--0000000000000143f50611b42bbd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi Armin,</div><div><br></div><div>Thank you for your=
reply.</div><div><br></div><div>> Try to translate with the option ``--=
withoutmod-cpyext``.</div><div><br></div><div>This option fixes the error, =
but now I encounter another error message (in pypy_module_sys.c):</div><div=
><br></div><div>```<br></div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 pypy_module_s=
ys.c: In function 'pypy_g_setrecursionlimit':<br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 pypy_module_sys.c:2890:9: warning: implicit declaration of funct=
ion 'OP_GC_INCREASE_ROOT_STACK_DEPTH' [-Wimplicit-function-declarat=
ion]<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02890 | =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 OP_GC_INCREASE_ROOT_STACK_DEPTH(l_v498959, /* nothing */);<br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^~~=
~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 pypy_module_sys=
.c:2890:65: error: expected expression before ')' token<br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A02890 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 OP_GC_INCREAS=
E_ROOT_STACK_DEPTH(l_v498959, /* nothing */);<br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ^<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 make: *** [Mak=
efile:641: pypy_module_sys.o] Error 1</div><div>```</div><div><br></div><di=
v>> Does the equivalent of<br>> `pypysrc\rpython\jit\backend\x86\test=
\test_zrpy_gc.py` pass on your<br>> backend?=C2=A0 I guess it does, and =
so does a long-running<br>> `test_zll_stress_*.py`---but maybe try to ru=
n `test_zll_stress_*.py`<br>> for even longer, it can often eventually f=
ind bugs if they are really<br>> in the JIT backend.</div><div><br></div=
><div>Yes.=C2=A0 test_zrpy_gc.py is passing.</div><div><br></div><div>I tri=
ed `test_zll_stress_*.py` and it passed too.=C2=A0 Then, I increased `total=
_iterations` to 10000 and decreased `pieces` to 1 and it still passed.</div=
><div><br></div><div>Just to be sure, is the following command correct?</di=
v><div><br></div><div>```<br></div><div>python2.7 ./pytest.py rpython/jit/b=
ackend/test/test_zll_stress_0.py -s -v</div><div>```</div><div><br></div><d=
iv>If everything is correct, I feel that I have to debug this the hard way.=
=C2=A0 Let's see if I can find more leads or not.=C2=A0 Thank you.</div=
><div><br></div><div>Regards,</div><div>Logan<br></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 16, 2024=
at 1:38=E2=80=AFAM Armin Rigo <<a href=3D"mailto:[email protected]">=
[email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">Hi Logan,<br>
<br>
On Fri, 16 Feb 2024 at 07:46, Logan Chien <<a href=3D"mailto:tzuhsiang.c=
[email protected]" target=3D"_blank">[email protected]</a>> wrote:<=
br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pypy_module_cpyext.c:125333:80: error=
: expected expression before ')' token<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0125333 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0OP_GC_RAWREFCOUNT_CREATE_LINK_PYOBJ(l_v451927, l_v451928, /* nothing =
*/);<br>
<br>
Ah, I guess that we are missing a dependency.=C2=A0 To compile with Boehm,<=
br>
you need to avoid this particular GC-related feature that is used by<br>
the cpyext module.=C2=A0 Try to translate with the option<br>
``--withoutmod-cpyext``.<br>
<br>
Does the equivalent of<br>
`pypysrc\rpython\jit\backend\x86\test\test_zrpy_gc.py` pass on your<br>
backend?=C2=A0 I guess it does, and so does a long-running<br>
`test_zll_stress_*.py`---but maybe try to run `test_zll_stress_*.py`<br>
for even longer, it can often eventually find bugs if they are really<br>
in the JIT backend.<br>
<br>
If it doesn't help, then "congratulation", you are in the lan=
d of<br>
debugging the very rare crash with gdb.=C2=A0 For this case, it's a mat=
ter<br>
of going earlier in time from the crash.=C2=A0 If the crash is nicely<br>
reproductible, then you have a chance of doing this by setting correct<br>
breakpoints (hardware breakpoints on memory change, for example) and<br>
restarting the program and repeating.=C2=A0 If it is too random, then that<=
br>
doesn't work; maybe look for what reverse debuggers are available<br>
nowadays.=C2=A0 Last I looked, on x86-64, gdb had a built-in but useless<br=
>
one (only goes backward a little bit), but there was lldb which<br>
worked, and udb was still called undodb---but my guess would be that<br>
none of that works on RISC-V.=C2=A0 If all else fails, I remember once<br>
hacking around to dump a huge amount of data (at least every single<br>
memory write into GC structures) (but that was outside the JIT;<br>
logging from generated assembly is made harder by the fact that the<br>
log calls must not cause the generated code to change apart from the<br>
calls).=C2=A0 It would let me know exactly what happened---that was for one=
<br>
bug that took me 10 days of hard work, my personal best :-/<br>
<br>
<br>
A bient=C3=B4t,<br>
<br>
Armin<br>
</blockquote></div>
--0000000000000143f50611b42bbd--
--===============5654457552565333750==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
pypy-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pypy-dev.python.org/
Member address: [email protected]
--===============5654457552565333750==--