GDB 13 Release 2022-09-11 update

GDB 13 Release 2022-09-11 update

[Joel Brobecker]

Hi everyone,

We are now in September, and I think now is a good time to start
working on our next major release.

Are there any issues we think should be fixed before we create
the GDB 13 branch?

Looking at the PRs targetting 13.1 in bugzilla
(https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&list_id=24362&product=gdb&query_format=advanced&target_milestone=13.1)

... I only see one "meta" bug related to TomT's new meta indexer.
Do we have a list of known remaining issues that we need to fix?

Anything else?

Thank you!
-- 
Joel

Re: GDB 13 Release 2022-09-11 update

[Philippe Waroquiers]

On Sun, 2022-09-11 at 11:26 -0700, Joel Brobecker via Gdb-patches wrote:
> Hi everyone,
> 
> We are now in September, and I think now is a good time to start
> working on our next major release.
> 
> Are there any issues we think should be fixed before we create
> the GDB 13 branch?
> 
> Looking at the PRs targetting 13.1 in bugzilla
> (https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&list_id=24362&product=gdb&query_format=advanced&target_milestone=13.1)
> 
> ... I only see one "meta" bug related to TomT's new meta indexer.
> Do we have a list of known remaining issues that we need to fix?
> 
> Anything else?

It would be nice to have the below reviewed and if ok pushed:
[RFAv3] Show locno for 'multi location' breakpoint hit msg+conv var $bkptno $locno. 
https://sourceware.org/pipermail/gdb-patches/2022-June/189824.html

Eli reviewed the doc, Keith did a first code review (these have led to RFAv2 and v3)
but there was no global maintainer review yet.

Thanks
Philippe

Re: GDB 13 Release 2022-09-11 update

[Tom de Vries]

On 9/11/22 20:26, Joel Brobecker via Gdb-patches wrote:
> Hi everyone,
> 
> We are now in September, and I think now is a good time to start
> working on our next major release.
> 
> Are there any issues we think should be fixed before we create
> the GDB 13 branch?
> 
> Looking at the PRs targetting 13.1 in bugzilla
> (https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&list_id=24362&product=gdb&query_format=advanced&target_milestone=13.1)
> 
> ... I only see one "meta" bug related to TomT's new meta indexer.
> Do we have a list of known remaining issues that we need to fix?
> 

Perhaps it would be worth clarifying the status of support for .gdb_index.

It is the defacto standard for the index cache, but ada support is 
broken ( https://sourceware.org/bugzilla/show_bug.cgi?id=29179 ).

Do we want to fix this?

Do we want to deprecate .gdb_index and start using .debug_names for the 
index cache?

Or are we fine with the status quo (which then might need documenting)?

Thanks,
- Tom

Re: GDB 13 Release 2022-09-11 update

[Tom Tromey]

Tom> Perhaps it would be worth clarifying the status of support for .gdb_index.

Tom> It is the defacto standard for the index cache, but ada support is
Tom> broken ( https://sourceware.org/bugzilla/show_bug.cgi?id=29179 ).

Tom> Do we want to fix this?

Tom> Do we want to deprecate .gdb_index and start using .debug_names for
Tom> the index cache?

Tom> Or are we fine with the status quo (which then might need documenting)?

My impression is that .gdb_index never really worked correctly for Ada.
So, while that is a regression of sorts, since the feature isn't really
usable for Ada in general, it doesn't seem worthwhile to fix it.

I did make .debug_names work for Ada.  See commit 3b00ef10a2a ("Add Ada
support for .debug_names").  I'm not at my work machine right now but
IIRC this is tested internally.

As for the overall plan, my view is:

* .gdb_index is (or should be) deprecated.  It was good but now we can
  do better.  However...

* In order to switch over fully, we have to fix the bugs in .debug_names.
  Fixing the writing side is easy (I have a patch somewhere) but I
  haven't worked on the reader yet.

* Once that is done we could switch over the index cache, but this also
  requires some more work to handle the situation where the index needs
  a string that isn't already in .debug_str.

I don't mind if this situation is documented.  We could even make
.gdb_index writing fail for Ada, though it seems to me that for the
index cache it is better to just fail silently.  Based on the Ada
programs I've seen, the new DWARF reader seems plenty fast enough
anyway.

Tom

Re: GDB 13 Release 2022-09-11 update

[Tom de Vries]

On 9/16/22 00:41, Tom Tromey wrote:
> Tom> Perhaps it would be worth clarifying the status of support for .gdb_index.
> 
> Tom> It is the defacto standard for the index cache, but ada support is
> Tom> broken ( https://sourceware.org/bugzilla/show_bug.cgi?id=29179 ).
> 
> Tom> Do we want to fix this?
> 
> Tom> Do we want to deprecate .gdb_index and start using .debug_names for
> Tom> the index cache?
> 
> Tom> Or are we fine with the status quo (which then might need documenting)?
> 
> My impression is that .gdb_index never really worked correctly for Ada.

Hmm, I committed 7ab96794115 ("[gdb/symtab] Enable ada .gdb_index").

So my understanding was that it was working, starting gdb 10, at least 
to the extent that running cc-with-gdb-index didn't show any regressions 
vs native for ada test-cases.

> So, while that is a regression of sorts, since the feature isn't really
> usable for Ada in general,

Um, can you elaborate a bit on why you think that?

> it doesn't seem worthwhile to fix it.
> 
> I did make .debug_names work for Ada.  See commit 3b00ef10a2a ("Add Ada
> support for .debug_names").  I'm not at my work machine right now but
> IIRC this is tested internally.
> 

Yeah, I also try to run cc-with-debug-names target board once in a while 
and report/fix regressions, and I don't see any ada-specific problems.

> As for the overall plan, my view is:
> 
> * .gdb_index is (or should be) deprecated.  It was good but now we can
>    do better.  However...
> 
> * In order to switch over fully, we have to fix the bugs in .debug_names.
>    Fixing the writing side is easy (I have a patch somewhere) but I
>    haven't worked on the reader yet.
> 
> * Once that is done we could switch over the index cache, but this also
>    requires some more work to handle the situation where the index needs
>    a string that isn't already in .debug_str.
> 
> I don't mind if this situation is documented.  We could even make
> .gdb_index writing fail for Ada, though it seems to me that for the
> index cache it is better to just fail silently.  Based on the Ada
> programs I've seen, the new DWARF reader seems plenty fast enough
> anyway.

The current failure mode is a disfunctional index, and consequently 
things are not being found, so there are lots of test-suite FAILs.

We could refuse to write an index (which would be non-silent), or we 
could even write an empty index (which could be silent, I think).

Thanks,
- Tom

Re: GDB 13 Release 2022-09-11 update

[Tom Tromey]

>> My impression is that .gdb_index never really worked correctly for
>> Ada.

Tom> Hmm, I committed 7ab96794115 ("[gdb/symtab] Enable ada .gdb_index").

Wow, I had completely forgotten about this.
I see I even wrote a corresponding documentation patch.

>> So, while that is a regression of sorts, since the feature isn't really
>> usable for Ada in general,

Tom> Um, can you elaborate a bit on why you think that?

Loss of memory.

Is there a bug open for this?  Anyway, I will look at it when I look
into the other issues with the new DWARF reader.

I looked and I can't find my patch to change how .debug_names is
constructed.  Hopefully that won't be too hard to rewrite.  However, I
did find a patch that I had forgotten about that changes .debug_names so
that it can write out a BFD, solving the string table problem (though I
still didn't write the reader side of this).

Tom

Re: GDB 13 Release 2022-09-11 update

[Tom de Vries]

On 9/20/22 01:26, Tom Tromey wrote:
>>> My impression is that .gdb_index never really worked correctly for
>>> Ada.
> 
> Tom> Hmm, I committed 7ab96794115 ("[gdb/symtab] Enable ada .gdb_index").
> 
> Wow, I had completely forgotten about this.
> I see I even wrote a corresponding documentation patch.
> 
>>> So, while that is a regression of sorts, since the feature isn't really
>>> usable for Ada in general,
> 
> Tom> Um, can you elaborate a bit on why you think that?
> 
> Loss of memory.
> 
> Is there a bug open for this?

Yes, https://sourceware.org/bugzilla/show_bug.cgi?id=29179 .

> Anyway, I will look at it when I look
> into the other issues with the new DWARF reader.
> 

OK.  FWIW, I don't mind if we drop this feature if it's difficult to 
repair or maintain going forward, or too expensive in terms of index 
size, I'm just trying to make sure that we don't silently regress.

> I looked and I can't find my patch to change how .debug_names is
> constructed.  Hopefully that won't be too hard to rewrite.  However, I
> did find a patch that I had forgotten about that changes .debug_names so
> that it can write out a BFD, solving the string table problem (though I
> still didn't write the reader side of this).

Hm, interesting.  Maybe you could post that patch to some PR?

Thanks,
- Tom