Re: GDB 13 release -- 2023-01-21 Update

[Joel Brobecker <brobecker@adacore.com>]

Hi Luis,

On Mon, Jan 30, 2023 at 11:23:06AM +0000, Luis Machado wrote:
> On 1/29/23 11:52, Joel Brobecker wrote:
> > > > > >      - 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.
> > > > > 
> > > > > That's what it seems to me.
> > > > > 
> > > > > I think another round of testing would be a good step to make sure there are no hidden bugs.
> > > > My understanding is that the problem was making debugging borderline
> > > > impossible.  Or at least, really, really unpleasant.  So I think it
> > > > qualifies as a bug fix, and that the benefit is worth the risk.
> > > 
> > > Right. Past a short number of frames, unwinding got really really slow.
> > 
> > The part that I haven't been clear on is whether this affected everyone
> > on Arm-32bit, or everyone on both Arm and AArch64, or just a subset
> > of the users?
> 
> Just a subset.
> 
> It affects 32-bit m-profile Arm targets that report the additional stack pointers.  This is either
> the org.gnu.gdb.arm.m-system feature or the org.gnu.gdb.arm.secext feature.
> 
> I'm fairly sure these features are only reported by emulators and bare-metal targets.
> 
> Now, a 64-bit gdb can debug 32-bit Arm as well, so you could have a 64-bit gdb running into this too
> if the target is a 32-bit m-profile Arm. But the target is still 32-bit Arm.
> 
> This doesn't affect AArch64 at all.

Thanks for the extra effort explaining the impact. This is much clear
for me, now. With your permission, I'd like to copy the text above
as a comment in the PR. Would that be OK?

> > Regardless of the above, I agree we can backport. To avoid confusion,
> > can I leave this to you, Luis, to confirm that the two patches I identified
> > previously are the only two patches that need to be backported, and
> > can you backport those for us, with a round of testing if you haven't
> > done so already, just to double-check?
> 
> Sure. I gave it a try with master and the test results look the same with or without the patches.
> 
> Unfortunately the 32-bit Arm test results are not too clean as there is quite a bit of noise from
> failing watchpoints tests.
> 
> I'll try with GDB 13 just to be sure.

Thank you. Once you've finished testing, whatever that might be,
you can go ahead and push the patches. As disussed earlier, we all
agree the risk of bad impact is very low.

Let me know when this is done. It's starting to look like we might
have a pre-release created this weekend! Maybe earlier, if I can
carve some time out of my work schedule.

> > For the record, those patches were:
> > 
> >      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
> > 
> > Thank you!
> 

-- 
Joel