GDB 13 release -- 2022-10-01 update

GDB 13 release -- 2022-10-01 update

[Joel Brobecker]

Hi everyone,

Nothing really new since the last update, except I forgot to
list a couple of PRs which were marked in bugzilla as targetting
GDB 13, related to Tom's new DWARF reader.

PhilippeW's is still waiting for a review...

Fixed Since the Previous Update:
--------------------------------

  <none>

Added Since the Last Update:
----------------------------

Some items which aren't new, but which I forgot to list in my previous
update:

  * [TomT] PR symtab/29105
    new DWARF reader still slow
    https://sourceware.org/bugzilla/show_bug.cgi?id=29105

    The subject of this PR and the initial message mention that
    the index cache is still faster than the new DWARF reader.
    But reading following discussions, it's not clear to me
    anymore what this ticket is about, or what's left to do.
    I will follow up on the PR itself.

  * [TomT] PR symtab/29106
    new DWARF reader should de-duplicate functions
    https://sourceware.org/bugzilla/show_bug.cgi?id=29106

Other Ongoing Items:
--------------------

  * [PhilippeW]
    Show locno for 'multi location' breakpoint hit msg+conv var $bkptno $locno

    v3 here: https://sourceware.org/pipermail/gdb-patches/2022-June/189824.html

  * [TomT] PR symtab/29179
    .gdb_index support for Ada
    https://sourceware.org/bugzilla/show_bug.cgi?id=29179

    TomT sent a patch:
    https://sourceware.org/pipermail/gdb-patches/2022-September/192056.html

Please let us know if there are other issues you think we should
fix before release GDB 13.

Thank you all!
-- 
Joel

Re: GDB 13 release -- 2022-10-01 update

[Torbjorn SVENSSON]

Hi Joel and the list,

I would like to land 2 patches for Cortex-M before the release.

* https://sourceware.org/bugzilla/show_bug.cgi?id=28549
* https://sourceware.org/pipermail/gdb-patches/2022-September/192223.html

Kind regards,
Torbjörn

On 2022-10-02 02:12, Joel Brobecker via Gdb-patches wrote:
> Hi everyone,
> 
> Nothing really new since the last update, except I forgot to
> list a couple of PRs which were marked in bugzilla as targetting
> GDB 13, related to Tom's new DWARF reader.
> 
> PhilippeW's is still waiting for a review...
> 
> Fixed Since the Previous Update:
> --------------------------------
> 
>    <none>
> 
> Added Since the Last Update:
> ----------------------------
> 
> Some items which aren't new, but which I forgot to list in my previous
> update:
> 
>    * [TomT] PR symtab/29105
>      new DWARF reader still slow
>      https://sourceware.org/bugzilla/show_bug.cgi?id=29105
> 
>      The subject of this PR and the initial message mention that
>      the index cache is still faster than the new DWARF reader.
>      But reading following discussions, it's not clear to me
>      anymore what this ticket is about, or what's left to do.
>      I will follow up on the PR itself.
> 
>    * [TomT] PR symtab/29106
>      new DWARF reader should de-duplicate functions
>      https://sourceware.org/bugzilla/show_bug.cgi?id=29106
> 
> Other Ongoing Items:
> --------------------
> 
>    * [PhilippeW]
>      Show locno for 'multi location' breakpoint hit msg+conv var $bkptno $locno
> 
>      v3 here: https://sourceware.org/pipermail/gdb-patches/2022-June/189824.html
> 
>    * [TomT] PR symtab/29179
>      .gdb_index support for Ada
>      https://sourceware.org/bugzilla/show_bug.cgi?id=29179
> 
>      TomT sent a patch:
>      https://sourceware.org/pipermail/gdb-patches/2022-September/192056.html
> 
> Please let us know if there are other issues you think we should
> fix before release GDB 13.
> 
> Thank you all!

Re: GDB 13 release -- 2022-10-01 update

[Joel Brobecker]

Hello Torbjorn,

> I would like to land 2 patches for Cortex-M before the release.
> 
> * https://sourceware.org/bugzilla/show_bug.cgi?id=28549

Can you provide more information about this one?

  - What's the motivation behind suggesting this PR? This will be
    important for us to know should resolution of this PR be delayed.

  - Have the latest version of the patches been submitted for review?
    If yes, can you provide URLs? In reading the PR, I am not really
    sure how many patches we are talking about, and where those patches
    migth be residing.

Thank you.

-- 
Joel

Re: GDB 13 release -- 2022-10-01 update

[Torbjorn SVENSSON]

Hi Joel,

On 2022-10-10 01:55, Joel Brobecker wrote:
> Hello Torbjorn,
> 
>> I would like to land 2 patches for Cortex-M before the release.
>>
>> * https://sourceware.org/bugzilla/show_bug.cgi?id=28549
> 
> Can you provide more information about this one?
> 
>    - What's the motivation behind suggesting this PR? This will be
>      important for us to know should resolution of this PR be delayed.

The motivation is simply that with the last improvements on the stack 
unwind on Cortex-M, the stack unwind can take a considerable amount of 
time (endless?) if the CPU is in lockup state.

>    - Have the latest version of the patches been submitted for review?
>      If yes, can you provide URLs? In reading the PR, I am not really
>      sure how many patches we are talking about, and where those patches
>      migth be residing.

I think Luis has the most up to date status here. Thomaz has created a 
single patch (https://sourceware.org/bugzilla/attachment.cgi?id=13853) 
that would handle the problematic case, but as there is no copyright on 
file for Tomaz, he needed to send one to FSF. A few weeks back, Thomaz 
did just that, but there has been no response from FSF.
The patch is in a sort-of-working state. There are some minor things to 
be addressed, but before the patch can be shared on the ML, the 
copyright pat must be handled.

> 
> Thank you.
> 

Re: GDB 13 release -- 2022-10-01 update

[Joel Brobecker]

> > > I would like to land 2 patches for Cortex-M before the release.
> > > 
> > > * https://sourceware.org/bugzilla/show_bug.cgi?id=28549
> > 
> > Can you provide more information about this one?
> > 
> >    - What's the motivation behind suggesting this PR? This will be
> >      important for us to know should resolution of this PR be delayed.
> 
> The motivation is simply that with the last improvements on the stack unwind
> on Cortex-M, the stack unwind can take a considerable amount of time
> (endless?) if the CPU is in lockup state.
> 
> >    - Have the latest version of the patches been submitted for review?
> >      If yes, can you provide URLs? In reading the PR, I am not really
> >      sure how many patches we are talking about, and where those patches
> >      migth be residing.
> 
> I think Luis has the most up to date status here. Thomaz has created a
> single patch (https://sourceware.org/bugzilla/attachment.cgi?id=13853) that
> would handle the problematic case, but as there is no copyright on file for
> Tomaz, he needed to send one to FSF. A few weeks back, Thomaz did just that,
> but there has been no response from FSF.
> The patch is in a sort-of-working state. There are some minor things to be
> addressed, but before the patch can be shared on the ML, the copyright pat
> must be handled.

OK; let's see what happens with the FSF assignment process.

It seems indeed desirable for us to include it in GDB 13, but I don't
think it will be blocking us if the patch gets delayed because
we're waiting for the assignment to come through (looking at progress
on the other issues, I think the FSF still has time). Worst case
scenario, if everything but this patch is done, we can start by
branching and creating our first pre-release. I think it'll be
relatively easy and safe to backport once the patch is approved.

Just for the avoidance of doubt, I assume you guys are finalizing
the patch in parallel to waiting for the FSF to get back to us,
right? Ideally, as soon as we have the paperwork done, the patch
gets pushed.

Thank you,
-- 
Joel

Re: GDB 13 release -- 2022-10-01 update

[Joel Brobecker]

> > > > I would like to land 2 patches for Cortex-M before the release.
> > > > 
> > > > * https://sourceware.org/bugzilla/show_bug.cgi?id=28549
> > > 
> > > Can you provide more information about this one?
> > > 
> > >    - What's the motivation behind suggesting this PR? This will be
> > >      important for us to know should resolution of this PR be delayed.
> > 
> > The motivation is simply that with the last improvements on the stack unwind
> > on Cortex-M, the stack unwind can take a considerable amount of time
> > (endless?) if the CPU is in lockup state.
> > 
> > >    - Have the latest version of the patches been submitted for review?
> > >      If yes, can you provide URLs? In reading the PR, I am not really
> > >      sure how many patches we are talking about, and where those patches
> > >      migth be residing.
> > 
> > I think Luis has the most up to date status here. Thomaz has created a
> > single patch (https://sourceware.org/bugzilla/attachment.cgi?id=13853) that
> > would handle the problematic case, but as there is no copyright on file for
> > Tomaz, he needed to send one to FSF. A few weeks back, Thomaz did just that,
> > but there has been no response from FSF.
> > The patch is in a sort-of-working state. There are some minor things to be
> > addressed, but before the patch can be shared on the ML, the copyright pat
> > must be handled.
> 
> OK; let's see what happens with the FSF assignment process.

Good news; I just received confirmation that the process is complete :-).

> It seems indeed desirable for us to include it in GDB 13, but I don't
> think it will be blocking us if the patch gets delayed because
> we're waiting for the assignment to come through (looking at progress
> on the other issues, I think the FSF still has time). Worst case
> scenario, if everything but this patch is done, we can start by
> branching and creating our first pre-release. I think it'll be
> relatively easy and safe to backport once the patch is approved.
> 
> Just for the avoidance of doubt, I assume you guys are finalizing
> the patch in parallel to waiting for the FSF to get back to us,
> right? Ideally, as soon as we have the paperwork done, the patch
> gets pushed.

-- 
Joel

Re: GDB 13 release -- 2022-10-01 update

[Torbjorn SVENSSON]

On 2022-10-10 09:40, Torbjorn SVENSSON wrote:
> Hi Joel,
> 
> On 2022-10-10 01:55, Joel Brobecker wrote:
>> Hello Torbjorn,
>>
>>> I would like to land 2 patches for Cortex-M before the release.
>>>
>>> * https://sourceware.org/bugzilla/show_bug.cgi?id=28549
>>
>> Can you provide more information about this one?
>>
>>    - What's the motivation behind suggesting this PR? This will be
>>      important for us to know should resolution of this PR be delayed.
> 
> The motivation is simply that with the last improvements on the stack 
> unwind on Cortex-M, the stack unwind can take a considerable amount of 
> time (endless?) if the CPU is in lockup state.
> 
>>    - Have the latest version of the patches been submitted for review?
>>      If yes, can you provide URLs? In reading the PR, I am not really
>>      sure how many patches we are talking about, and where those patches
>>      migth be residing.
> 
> I think Luis has the most up to date status here. Thomaz has created a 
> single patch (https://sourceware.org/bugzilla/attachment.cgi?id=13853) 
> that would handle the problematic case, but as there is no copyright on 
> file for Tomaz, he needed to send one to FSF. A few weeks back, Thomaz 
> did just that, but there has been no response from FSF.
> The patch is in a sort-of-working state. There are some minor things to 
> be addressed, but before the patch can be shared on the ML, the 
> copyright pat must be handled.
> 
>>
>> Thank you.
>>


With the merges today (thank you Luis for those!), I no longer have any 
item for the GDB 13 release.

I would say that it would be nice to have the sN <--> dM pseudo register 
sync fixed, but I fear that it's a bigger topic and that the time left 
until the release is not enough to get it into a mergeable state.

Kind regards,
Torbjörn

Re: GDB 13 release -- 2022-10-01 update

[Joel Brobecker]

> With the merges today (thank you Luis for those!), I no longer have any item
> for the GDB 13 release.

Great. Thanks for confirming, Torbjörn.

> I would say that it would be nice to have the sN <--> dM pseudo
> register sync fixed, but I fear that it's a bigger topic and that the
> time left until the release is not enough to get it into a mergeable
> state.

Makes sense.

-- 
Joel