Message ID | 20241211201739.1380222-1-peterx@redhat.com (mailing list archive) |
---|---|
Headers | show |
Series | scripts/qemu-gdb: Make coroutine dumps to work with coredumps | expand |
Peter Xu <peterx@redhat.com> writes: > Coroutines are used in many cases in block layers. It's also used in live > migration when on destination side, and it'll be handy to diagnose crashes > within a coroutine when we want to also know what other coroutines are > doing. Not sure if you've seen this message on the list: https://lore.kernel.org/r/f0ebccca-7a17-4da8-ac4a-71cf6d69abc3@mtasv.net
On Wed, Dec 11, 2024 at 05:25:10PM -0300, Fabiano Rosas wrote: > Peter Xu <peterx@redhat.com> writes: > > > Coroutines are used in many cases in block layers. It's also used in live > > migration when on destination side, and it'll be handy to diagnose crashes > > within a coroutine when we want to also know what other coroutines are > > doing. > > Not sure if you've seen this message on the list: > > https://lore.kernel.org/r/f0ebccca-7a17-4da8-ac4a-71cf6d69abc3@mtasv.net No I didn't. I only started looking at this because I got a bug a few days ago that I need to look at the main coroutine where dest crashed, then Stefan told me this script and also told me it only works with live session. Ideally I'll need coredump debug-ability, then I figured it isn't too hard. I saw that it didn't yet land gdb, and it's much more involved even if it could be more generic. Not sure how the block developers think, personally I prefer this much smaller change because it works on old systems, where I can easily install gdb with package managers.
Am 11.12.2024 um 22:39 hat Peter Xu geschrieben: > On Wed, Dec 11, 2024 at 05:25:10PM -0300, Fabiano Rosas wrote: > > Peter Xu <peterx@redhat.com> writes: > > > > > Coroutines are used in many cases in block layers. It's also used in live > > > migration when on destination side, and it'll be handy to diagnose crashes > > > within a coroutine when we want to also know what other coroutines are > > > doing. > > > > Not sure if you've seen this message on the list: > > > > https://lore.kernel.org/r/f0ebccca-7a17-4da8-ac4a-71cf6d69abc3@mtasv.net Let me add Niall to this thread. > No I didn't. I only started looking at this because I got a bug a few days > ago that I need to look at the main coroutine where dest crashed, then > Stefan told me this script and also told me it only works with live session. > Ideally I'll need coredump debug-ability, then I figured it isn't too hard. I agree this is useful at least in the current state of things, and possibly in the future for QEMUs built without support for new gdb magic. > I saw that it didn't yet land gdb, and it's much more involved even if it > could be more generic. Not sure how the block developers think, personally > I prefer this much smaller change because it works on old systems, where I > can easily install gdb with package managers. I don't think this is a question of preferring one or the other! Your simple change works today with existing QEMU builds and has fewer requirements, but it's also more limited in functionality. The gdb changes look really nice at the first sight, debugging coroutines as if they were threads is exactly what you want in most cases. So I'd love to see this. Of course, someone would have to first understand what needs to be done in detail and then implement the QEMU side of it once the gdb side is merged. Kevin
On Thu, Dec 12, 2024 at 11:28:52AM +0100, Kevin Wolf wrote: > Am 11.12.2024 um 22:39 hat Peter Xu geschrieben: > > On Wed, Dec 11, 2024 at 05:25:10PM -0300, Fabiano Rosas wrote: > > > Peter Xu <peterx@redhat.com> writes: > > > > > > > Coroutines are used in many cases in block layers. It's also used in live > > > > migration when on destination side, and it'll be handy to diagnose crashes > > > > within a coroutine when we want to also know what other coroutines are > > > > doing. > > > > > > Not sure if you've seen this message on the list: > > > > > > https://lore.kernel.org/r/f0ebccca-7a17-4da8-ac4a-71cf6d69abc3@mtasv.net > > Let me add Niall to this thread. > > > No I didn't. I only started looking at this because I got a bug a few days > > ago that I need to look at the main coroutine where dest crashed, then > > Stefan told me this script and also told me it only works with live session. > > Ideally I'll need coredump debug-ability, then I figured it isn't too hard. > > I agree this is useful at least in the current state of things, and > possibly in the future for QEMUs built without support for new gdb > magic. > > > I saw that it didn't yet land gdb, and it's much more involved even if it > > could be more generic. Not sure how the block developers think, personally > > I prefer this much smaller change because it works on old systems, where I > > can easily install gdb with package managers. > > I don't think this is a question of preferring one or the other! Your > simple change works today with existing QEMU builds and has fewer > requirements, but it's also more limited in functionality. Ah, definitely.. I had no intention to mean that we should only merge one, but more of pure thinking what I would like to use in the near future, even if the solution landed at some point in both gdb and qemu. I'll still need to look at the old systems that miss the generic solution, so I'd still prefer using the scripts (which currently satisfies most of my needs..). > > The gdb changes look really nice at the first sight, debugging > coroutines as if they were threads is exactly what you want in most > cases. So I'd love to see this. Of course, someone would have to first > understand what needs to be done in detail and then implement the QEMU > side of it once the gdb side is merged. Yes, I wish that could happen some day, that by default gdb on top of QEMU can dump coroutines. Thanks,