|
From: | Luis Machado |
Subject: | Re: [PATCH 09/11] tests/tcg: disable pauth for aarch64 gdb tests |
Date: | Fri, 17 Mar 2023 17:16:16 +0000 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 |
On 3/17/23 17:12, Luis Machado wrote:
On 3/17/23 17:07, Peter Maydell wrote:On Fri, 17 Mar 2023 at 16:55, Luis Machado <luis.machado@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.Just to clarify, there won't be any point releases for gdb's 9/10/11/12. We might have a bug fix release for gdb 13 though (which isn't affected).
Just to complement, my plan is to make the backports available (via stable branch commits) so distro package maintainers can pick those up easily. No new releases will be made for older gdb's, so the package maintainers can pick the backport up as soon as they are pushed. There won't be waiting for a new release of gdb.
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.Fair enough.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.I can negotiate that as well, though it borders being a new feature.thanks -- PMM
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
[Prev in Thread] | Current Thread | [Next in Thread] |