Message ID | 160006358590.31457.16757371597343007847.stgit@pasha-ThinkPad-X280 (mailing list archive) |
---|---|
Headers | show |
Series | Reverse debugging | expand |
On 14/09/20 08:06, Pavel Dovgalyuk wrote: > GDB remote protocol supports reverse debugging of the targets. > It includes 'reverse step' and 'reverse continue' operations. > The first one finds the previous step of the execution, > and the second one is intended to stop at the last breakpoint that > would happen when the program is executed normally. > > Reverse debugging is possible in the replay mode, when at least > one snapshot was created at the record or replay phase. > QEMU can use these snapshots for travelling back in time with GDB. I had queued this, it is a very nice patch series. Unfortunately, the tests failed on gitlab: https://gitlab.com/bonzini/qemu/-/jobs/745795080 Paolo
On 20.09.2020 10:58, Paolo Bonzini wrote: > On 14/09/20 08:06, Pavel Dovgalyuk wrote: >> GDB remote protocol supports reverse debugging of the targets. >> It includes 'reverse step' and 'reverse continue' operations. >> The first one finds the previous step of the execution, >> and the second one is intended to stop at the last breakpoint that >> would happen when the program is executed normally. >> >> Reverse debugging is possible in the replay mode, when at least >> one snapshot was created at the record or replay phase. >> QEMU can use these snapshots for travelling back in time with GDB. > > I had queued this, it is a very nice patch series. Unfortunately, the > tests failed on gitlab: > > https://gitlab.com/bonzini/qemu/-/jobs/745795080 There is a strange thing in your environment: 15:49:41 INFO | Downloading/preparing boot image 15:49:42 INFO | Running '/builds/bonzini/qemu/build/qemu-img create -f qcow2 -b /builds/bonzini/qemu/avocado-cache/by_location/d2a8d6b607afec50de14560c064f34ffd99836b2/Fedora-Cloud-Base-31-1.9.x86_64.qcow2 /var/tmp/avocado_tj2janfx/avocado_job_ys7ueohj/04-tests_acceptance_boot_linux.py_BootLinuxX8664.test_pc_q35_kvm/Fedora-Cloud-Base-31-1.9.x86_64-d1ac1224.qcow2' It downloads boot image, but there is no such requirement in the test. And all this stuff consumes most of the time for the test. Pavel Dovgalyuk
On 21.09.2020 09:03, Pavel Dovgalyuk wrote: > On 20.09.2020 10:58, Paolo Bonzini wrote: >> On 14/09/20 08:06, Pavel Dovgalyuk wrote: >>> GDB remote protocol supports reverse debugging of the targets. >>> It includes 'reverse step' and 'reverse continue' operations. >>> The first one finds the previous step of the execution, >>> and the second one is intended to stop at the last breakpoint that >>> would happen when the program is executed normally. >>> >>> Reverse debugging is possible in the replay mode, when at least >>> one snapshot was created at the record or replay phase. >>> QEMU can use these snapshots for travelling back in time with GDB. >> >> I had queued this, it is a very nice patch series. Unfortunately, the >> tests failed on gitlab: >> >> https://gitlab.com/bonzini/qemu/-/jobs/745795080 > > There is a strange thing in your environment: > > 15:49:41 INFO | Downloading/preparing boot image > 15:49:42 INFO | Running '/builds/bonzini/qemu/build/qemu-img create -f > qcow2 -b > /builds/bonzini/qemu/avocado-cache/by_location/d2a8d6b607afec50de14560c064f34ffd99836b2/Fedora-Cloud-Base-31-1.9.x86_64.qcow2 > /var/tmp/avocado_tj2janfx/avocado_job_ys7ueohj/04-tests_acceptance_boot_linux.py_BootLinuxX8664.test_pc_q35_kvm/Fedora-Cloud-Base-31-1.9.x86_64-d1ac1224.qcow2' > > > > It downloads boot image, but there is no such requirement in the test. > And all this stuff consumes most of the time for the test. Sorry, that was ok. It was the output from the previous test. For reverse debugging there was a timeout on reading from the socket: result = self._socket.recv(REMOTE_MAX_PACKET_SIZE) Do you have any hint how to debug such a failure in this environment? Pavel Dovgalyuk
On 20.09.2020 10:58, Paolo Bonzini wrote: > On 14/09/20 08:06, Pavel Dovgalyuk wrote: >> GDB remote protocol supports reverse debugging of the targets. >> It includes 'reverse step' and 'reverse continue' operations. >> The first one finds the previous step of the execution, >> and the second one is intended to stop at the last breakpoint that >> would happen when the program is executed normally. >> >> Reverse debugging is possible in the replay mode, when at least >> one snapshot was created at the record or replay phase. >> QEMU can use these snapshots for travelling back in time with GDB. > > I had queued this, it is a very nice patch series. Unfortunately, the > tests failed on gitlab: > > https://gitlab.com/bonzini/qemu/-/jobs/745795080 There are other tests that were disabled on gitlab for the unknown reason. https://patchwork.kernel.org/patch/11636515/ https://patchwork.kernel.org/patch/11701681/ The latter is related to machine_rx_gdbsim.py Could it be the same avocado/python/etc issue with socket interaction? Pavel Dovgalyuk
On 9/21/20 8:48 AM, Pavel Dovgalyuk wrote: > On 20.09.2020 10:58, Paolo Bonzini wrote: >> On 14/09/20 08:06, Pavel Dovgalyuk wrote: >>> GDB remote protocol supports reverse debugging of the targets. >>> It includes 'reverse step' and 'reverse continue' operations. >>> The first one finds the previous step of the execution, >>> and the second one is intended to stop at the last breakpoint that >>> would happen when the program is executed normally. >>> >>> Reverse debugging is possible in the replay mode, when at least >>> one snapshot was created at the record or replay phase. >>> QEMU can use these snapshots for travelling back in time with GDB. >> >> I had queued this, it is a very nice patch series. Unfortunately, the >> tests failed on gitlab: >> >> https://gitlab.com/bonzini/qemu/-/jobs/745795080 > > There are other tests that were disabled on gitlab for the unknown reason. > > https://patchwork.kernel.org/patch/11636515/ Unrelated. > https://patchwork.kernel.org/patch/11701681/ > > The latter is related to machine_rx_gdbsim.py Unrelated, 'gdbsim' is the name of the machine. It is not using the gdbstub/gdb protocol. > Could it be the same avocado/python/etc issue with socket interaction? Yes, likely... The kludge is to simply add (with an explanation if possible): @skipIf(os.getenv('GITLAB_CI'), 'Running on GitLab') > > > Pavel Dovgalyuk > >