Re: [PATCH 09/11] tests/tcg: disable pauth for aarch64 gdb tests

[Luis Machado]

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.