GDB 13 release -- 2023-01-21 Update

[Joel Brobecker]

Hello,

> >    * [Torbjorn] tdep/29738
> >      Arm M-profile dwarf2 unwinder performance suffers from exponential growth
> >      https://sourceware.org/bugzilla/show_bug.cgi?id=29738
> > 
> >      patch v3, 2023-01-19, reviewed 2023-01-20:
> >      https://sourceware.org/pipermail/gdb-patches/2023-January/195915.html
> 
> I just pushed this for master.
> Is it okay to also push the 2 patches to gdb-13-branch?

For the avoidance of doubt, my understanding is that we are talking
about the following two patches:

    commit d72ba177c85f2ad18d0dcabdd8844532c9acb819
    Author: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
    Date:   Thu Nov 17 12:17:53 2022 +0100
    Subject: gdb: dwarf2 generic implementation for caching function data

... and ...

    commit 5cf11483141a58314834653003e49709b47822d5
    Author: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
    Date:   Thu Nov 17 12:18:20 2022 +0100
    Subject: gdb/arm: Use new dwarf2 function cache

I hope I having missed any other patch!

The first one adds, as the subject indicates, a framework for
caching frame-related information, and the second patch takes
advantage of that framework,

Luis marked the corresponding PR as "important to fix", so
I'm assuming the impact if we do not backport is significant
(exponentional performance degradation). I was confused into
thinking that this would "only" impact Cortex-m without security
extensions, but maybe it's the opposite actually.

So the next question is, what is the potential impact if we
backport the patch and there is a bug in it:

  - Well, it touches the generic Arm unwinding code, so
    worse case scenario, DWARF-based unwinding is broken?

  - With that said, the patch appears to simply add a cache,
    so the logic of it all doesn't appear to be extremely
    complicated. So I would rate the risk to be low.

If Tom and/or Simon agree, my assessment is that it is fine
to backport those two patches onto the gdb-13 branch.

-- 
Joel