Pavel Dovgalyuk <dovga...@ispras.ru> writes:
>> From: Paolo Bonzini [mailto:pbonz...@redhat.com] >> On 17/10/2018 13:38, Pavel Dovgalyuk wrote: >> >> From: Paolo Bonzini [mailto:pbonz...@redhat.com] >> >> On 17/10/2018 11:53, Artem Pisarenko wrote: >> >>> See my last comment in bug report. This kind of modification, even >> >>> adapted to changed function name, doesn't solve issue. >> >>> I thought long time that it does, but once I catched qemu with a hang. >> >>> And of course, I wasn't able to reproduce it. So it just better hides >> >>> issue. >> >>> Take a look at alternative solution from >> >>> QBox: >> >>> https://git.greensocs.com/qemu/qbox/commit/a8ed106032e375e715a531d6e93e4d9ec295dbdb >> >>> I didn't catched fail with it (yet). >> > >> > Tried to test it, but rr seems to be broken again. >> > I'll try to bisect now. >> >> Can we add a test that runs with "make check" and covers the basics of >> record/replay's cpus.c bits? > > I thought Alex is trying to create some tests. > Alex, am I right? Not actively at the moment but we need to get there. As rr only works with system emulation we need to update the check-tcg machinery to be able to build some system binaries. A number of the tests/tcg targets already have some system binaries waiting to be ported to the new make system. The next question is what we need to exercise rr? The migration tests have added some very simple ping-pong type "boot sectors" so perhaps putting the source for those into check-tcg we can build them and use it for rr testing? -- Alex Bennée
