From: Joel Brobecker <brobecker@adacore.com>
To: Torbjorn SVENSSON <torbjorn.svensson@foss.st.com>,
simon.marchi@polymtl.ca, tom@tromey.com
Cc: Joel Brobecker <brobecker@adacore.com>,
gdb-patches@sourceware.org, luis.machado@arm.com
Subject: Re: GDB 13 release -- 2023-01-21 Update
Date: Fri, 27 Jan 2023 10:30:24 +0400 [thread overview]
Message-ID: <Y9NvgBUvtCBfp0Qi@adacore.com> (raw)
In-Reply-To: <95dc547e-59f8-95b3-903c-138d8842cea0@foss.st.com>
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
next prev parent reply other threads:[~2023-01-27 6:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-21 6:08 Joel Brobecker
2023-01-25 20:18 ` Torbjorn SVENSSON
2023-01-27 6:30 ` Joel Brobecker [this message]
2023-01-27 6:38 ` Luis Machado
2023-01-27 17:17 ` Simon Marchi
2023-01-28 8:39 ` Luis Machado
2023-01-29 11:52 ` Joel Brobecker
2023-01-30 11:23 ` Luis Machado
2023-01-31 7:03 ` Joel Brobecker
2023-01-31 13:57 ` Luis Machado
2023-01-31 14:33 ` Luis Machado
2023-02-02 3:44 ` Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y9NvgBUvtCBfp0Qi@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=luis.machado@arm.com \
--cc=simon.marchi@polymtl.ca \
--cc=tom@tromey.com \
--cc=torbjorn.svensson@foss.st.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).