On Fri, 17 Mar 2023 at 16:55, Luis Machado <luis.mach...@arm.com> wrote: > On 3/17/23 16:37, Peter Maydell wrote: > > Having run into this problem in another couple of situations, one of > > which involved gdb 10, I think I'm increasingly favouring option > > 2 here. The affected gdbs seem to be quite widely deployed, and > > the bug results in crashes even for users who didn't really > > care about pauth. So I'd rather we didn't release a QEMU 8.0 > > which crashes these affected deployed gdbs. > > > > Are the affected gdb's packaged by distros? If so, a backport the distros can > pick up > will solve this in a quick package update.
Yes, it's exactly because these gdbs are distro-packaged that I don't want QEMU to make them crash. I think it's going to take a long time for the fix to go into gdb branches and gdb to make a point release and distros to pick up that point release, and in the meantime that's a lot of crashing gdb bug reports that we're going to have to field. > If we decide qemu should now emit a different xml for pauth, it will fix the > crashes, but it also > means older gdb's (9/10/11/12) will not be able to backtrace properly through > pauth-signed frames. > > Maybe that's a reasonable drawback for qemu users? "No backtrace through pauth frames" is the situation we've been in ever since we implemented pauth in 2019, so I think that's fine. It's not regressing something that used to work. > If someone decides to implement a debugging stub that reports pauth (fast > models, for example), it will > also crash gdb, so I still plan to do the backport anyway. If you're backporting the fix, you could also backport the (hopefully tiny) change that says "treat pauth_v2 the same way we do pauth", and then users with an updated older gdb will also get working backtraces. thanks -- PMM