[ANNOUNCEMENT] GDB 16.1 released!

[ANNOUNCEMENT] GDB 16.1 released!

[Joel Brobecker via Gdb-announce via Gdb]

            GDB 16.1 released!

Release 16.1 of GDB, the GNU Debugger, is now available.  GDB is
a source-level debugger for Ada, C, C++, Fortran, Go, Rust, and many
other languages.  GDB can target (i.e., debug programs running on)
more than a dozen different processor architectures, and GDB itself
can run on most popular GNU/Linux, Unix and Microsoft Windows variants.
GDB is free (libre) software.

You can download GDB from the GNU HTTPS server in the directory:

        https://ftp.gnu.org/gnu/gdb/?C=M;O=D

The vital stats:

  Size   sha256sum                                                         Name
  24MiB  c2cc5ccca029b7a7c3879ce8a96528fdfd056b4d884f2b0511e8f7bc723355c6  gdb-16.1.tar.xz
  40MiB  ff2cfff60546a3851561ddac7c012a7c184bb95b66286ae332d16880f77247c9  gdb-16.1.tar.gz

There is a web page for GDB at:

        https://www.gnu.org/software/gdb/

That page includes information about GDB mailing lists (an announcement
mailing list, developers discussion lists, etc.), details on how to
access GDB's source repository, locations for development snapshots,
preformatted documentation, and links to related information around
the net.  We will put errata notes and host-specific tips for this release
on-line as any problems come up.  All mailing lists archives are also
browsable via the web.

GDB 16.1 includes the following changes and enhancements:

* record/replay support now available on loongarch*-linux*

* GDB now supports watchpoints for tagged data pointers.

* MTE (Memory Tagging Extension) debugging is now supported on AArch64
   baremetal.

* New bash script gstack uses GDB to print stack traces of running processes.

* Enhanced breakpoint support

  ** For breakpoints that are created in the 'pending' state, any
     'thread' or 'task' keywords are parsed at the time the breakpoint is
     created, rather than at the time the breakpoint becomes non-pending.

  ** Thread-specific breakpoints are only inserted into the program space
     in which the thread of interest is running.

* Enhanced Intel Processor Trace support

  ** Support for printing of asynchronous events

  ** Support for printing of ptwrite payloads

* Changed commands

  ** The "remove-symbol-file -a ADDRESS" command now accepts a full expression
     as the ADDRESS.

  ** The "show configuration" command now prints the version of GNU
     readline that GDB is using.

  ** The "maintenance print remote-registers" now provides an "Expedited"
     column indicating which registers were included in the last stop reply
     packet received by GDB.

  ** Various command taking filenames as argument now require file names
     to be quoted if the argument contains white spaces or quote characters.

* Python API changes

  ** New module gdb.missing_objfile that facilitates dealing with
     missing objfiles when opening a core-file. GDB commands to query,
     enable and disable handlers created using this API have also
     been added.

  ** New event gdb.tui_enabled.

  ** Added the gdb.Symbol.is_artificial attribute.

  ** New gdb.record.clear function to clear the trace data of
     the current recording.

  ** The 'signed' argument to gdb.Architecture.integer_type() will no
     longer accept non-bool types.

  ** The gdb.MICommand.installed property can only be set to True or
     False.

  ** The 'qualified' argument to gdb.Breakpoint constructor will no
     longer accept non-bool types.

* Debugger Adapter Protocol changes

  ** The "scopes" request will now return a scope holding global
     variables from the stack frame's compilation unit.

  ** The "scopes" request will return a "returnValue" scope holding
     the return value from the latest "stepOut" command, when
     appropriate.

  ** The "launch" and "attach" requests were rewritten in accordance
     with some clarifications to the spec.  Now they can be sent at
     any time after the "initialized" event, but will not take effect
     (or send a response) until after the "configurationDone" request
     has been sent.

  ** The "variables" request will not return artificial symbols.

* Remote Protocol

  ** New remote packet: vFile:stat

  ** New remote packet: x addr,length

* Miscellaneous

  ** The Ada 'Object_Size attribute is now supported.

  ** Styling now available for line numbers, GDB commands and header lines
     of lists.

  ** It is now possible to turn the warning emitted when specifying
     a language that does not match the current frame off.

  ** For ARM targets, the offset of the pc in the jmp_buf has been fixed
     to match glibc 2.20 and later.  This should only matter when not
     using libc probes.  This may cause breakage when using an incompatible
     libc, like uclibc or newlib, or an older glibc.

* Deprecated or removed

  ** Support for QNX Neutrino has been removed
  ** Support for Nios II targets has been removed
  ** Support for Intel MPX has been removed

For a complete list and more details on each item, please see the gdb/NEWS
file, available at:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=gdb/NEWS;hb=gdb-16.1-release

-- 
Joel Brobecker

Re: [ANNOUNCEMENT] GDB 16.1 released!

[Andrew Burgess via Gdb]

Joel Brobecker via Gdb-announce via Gdb <gdb@sourceware.org> writes:

>             GDB 16.1 released!

Bug https://sourceware.org/bugzilla/show_bug.cgi?id=32578 was reported
against the release.

Consider these steps:

  $ tar -xf gdb-16.1.tar.xz
  $ cd gdb-16.1
  $ mkdir build
  $ cd build
  $ ../configure
  $ make all

This will fail due to issues with the bfd docs; the pre-generated .texi
files are not symlinked into the build tree correctly.

The above is not how we recommend building GDB in gdb/README, our
suggestion is instead:

  $ tar -xf gdb-16.1.tar.xz
  $ cd gdb-16.1
  $ ./configure
  $ make all

This works just fine as the pre-generated .texi files are already in the
expected location, and no symlinks need to be created.

Additionally, in the first case, if you configure with an absolute path
then everything will work fine.

I've posted a fix to the bfd tree here:

  https://inbox.sourceware.org/binutils/40a989ffc81a9b07b5dd70f00521dd2171d7a200.1737465905.git.aburgess@redhat.com

If/when this is merged I do plan to back-port this to the gdb-16-branch,
but given the build following the suggested steps works fine, I'm not
sure this justifies a follow up release.  But I wanted to raise this for
discussion.

Thanks,
Andrew

Re: [ANNOUNCEMENT] GDB 16.1 released!

[Joel Brobecker via Gdb]

[Apologies for the resend, Andrew - wrong email address for the gdb
mailing-list]

> If/when this is merged I do plan to back-port this to the gdb-16-branch,
> but given the build following the suggested steps works fine, I'm not
> sure this justifies a follow up release.  But I wanted to raise this for
> discussion.

I fear that using a relative path to configure when building out-of-tree
might be fairly common. Thankfully, the workaround is relatively
straightforward, so once users get the answer, they can move forward
quickly, but getting this answer may not be straightforward.

It might be worth doing a first corrective release right away.
-- 
Joel

Re: [ANNOUNCEMENT] GDB 16.1 released!

[Andrew Burgess via Gdb]

Joel Brobecker <brobecker@adacore.com> writes:

> [Apologies for the resend, Andrew - wrong email address for the gdb
> mailing-list]
>
>> If/when this is merged I do plan to back-port this to the gdb-16-branch,
>> but given the build following the suggested steps works fine, I'm not
>> sure this justifies a follow up release.  But I wanted to raise this for
>> discussion.
>
> I fear that using a relative path to configure when building out-of-tree
> might be fairly common. Thankfully, the workaround is relatively
> straightforward, so once users get the answer, they can move forward
> quickly, but getting this answer may not be straightforward.
>
> It might be worth doing a first corrective release right away.

The bfd fix was approved and merged to master.  I have also pushed the
fix to the gdb-16-branch.  If we did want a corrective fix then we have
everything we need in place.

Thanks,
Andrew

Re: [ANNOUNCEMENT] GDB 16.1 released!

[Joel Brobecker via Gdb]

> >> If/when this is merged I do plan to back-port this to the gdb-16-branch,
> >> but given the build following the suggested steps works fine, I'm not
> >> sure this justifies a follow up release.  But I wanted to raise this for
> >> discussion.
> >
> > I fear that using a relative path to configure when building out-of-tree
> > might be fairly common. Thankfully, the workaround is relatively
> > straightforward, so once users get the answer, they can move forward
> > quickly, but getting this answer may not be straightforward.
> >
> > It might be worth doing a first corrective release right away.
> 
> The bfd fix was approved and merged to master.  I have also pushed the
> fix to the gdb-16-branch.  If we did want a corrective fix then we have
> everything we need in place.

Great news!

What's the general sentiment towards the corrective release?
Do people agree that it's worth the effort doing on now?

-- 
Joel

Re: [ANNOUNCEMENT] GDB 16.1 released!

[Andrew Burgess via Gdb]

Joel Brobecker <brobecker@adacore.com> writes:

>> >> If/when this is merged I do plan to back-port this to the gdb-16-branch,
>> >> but given the build following the suggested steps works fine, I'm not
>> >> sure this justifies a follow up release.  But I wanted to raise this for
>> >> discussion.
>> >
>> > I fear that using a relative path to configure when building out-of-tree
>> > might be fairly common. Thankfully, the workaround is relatively
>> > straightforward, so once users get the answer, they can move forward
>> > quickly, but getting this answer may not be straightforward.
>> >
>> > It might be worth doing a first corrective release right away.
>> 
>> The bfd fix was approved and merged to master.  I have also pushed the
>> fix to the gdb-16-branch.  If we did want a corrective fix then we have
>> everything we need in place.
>
> Great news!
>
> What's the general sentiment towards the corrective release?
> Do people agree that it's worth the effort doing on now?

I don't want to impose unnecessary additional work on you, but my
feeling is that a corrective release would be a good idea given that
configuring using '../configure' isn't a totally crazy thing to do.

But would be nice to see what others think.

Thanks,
Andrew

Re: [ANNOUNCEMENT] GDB 16.1 released!

[Andrew Burgess via Gdb]

Andrew Burgess <aburgess@redhat.com> writes:

> Joel Brobecker <brobecker@adacore.com> writes:
>
>>> >> If/when this is merged I do plan to back-port this to the gdb-16-branch,
>>> >> but given the build following the suggested steps works fine, I'm not
>>> >> sure this justifies a follow up release.  But I wanted to raise this for
>>> >> discussion.
>>> >
>>> > I fear that using a relative path to configure when building out-of-tree
>>> > might be fairly common. Thankfully, the workaround is relatively
>>> > straightforward, so once users get the answer, they can move forward
>>> > quickly, but getting this answer may not be straightforward.
>>> >
>>> > It might be worth doing a first corrective release right away.
>>> 
>>> The bfd fix was approved and merged to master.  I have also pushed the
>>> fix to the gdb-16-branch.  If we did want a corrective fix then we have
>>> everything we need in place.
>>
>> Great news!
>>
>> What's the general sentiment towards the corrective release?
>> Do people agree that it's worth the effort doing on now?
>
> I don't want to impose unnecessary additional work on you, but my
> feeling is that a corrective release would be a good idea given that
> configuring using '../configure' isn't a totally crazy thing to do.
>
> But would be nice to see what others think.

And we should decide what we want to do about:

  https://inbox.sourceware.org/gdb-patches/CAOp6jLYD0g-GUsx7jhO3g8H_4pHkB6dkh51cbyDT-5yMfQwu+A@mail.gmail.com

Before making any follow on release.

Thanks,
Andrew

Re: [ANNOUNCEMENT] GDB 16.1 released!

[Joel Brobecker via Gdb]

> And we should decide what we want to do about:
> 
>   https://inbox.sourceware.org/gdb-patches/CAOp6jLYD0g-GUsx7jhO3g8H_4pHkB6dkh51cbyDT-5yMfQwu+A@mail.gmail.com
> 
> Before making any follow on release.

Agreed!

Beyond that, we shouldn't worry about the effort needed to create
a new release. It's not that much, especially for corrective releases.
So let's do a quick corrective release once we know more about
this other new issue.

-- 
Joel

Re: [ANNOUNCEMENT] GDB 16.1 released!

[Luis Machado via Gdb]

On 1/22/25 19:55, Andrew Burgess via Gdb wrote:
> Joel Brobecker <brobecker@adacore.com> writes:
> 
>>>>> If/when this is merged I do plan to back-port this to the gdb-16-branch,
>>>>> but given the build following the suggested steps works fine, I'm not
>>>>> sure this justifies a follow up release.  But I wanted to raise this for
>>>>> discussion.
>>>>
>>>> I fear that using a relative path to configure when building out-of-tree
>>>> might be fairly common. Thankfully, the workaround is relatively
>>>> straightforward, so once users get the answer, they can move forward
>>>> quickly, but getting this answer may not be straightforward.
>>>>
>>>> It might be worth doing a first corrective release right away.
>>>
>>> The bfd fix was approved and merged to master.  I have also pushed the
>>> fix to the gdb-16-branch.  If we did want a corrective fix then we have
>>> everything we need in place.
>>
>> Great news!
>>
>> What's the general sentiment towards the corrective release?
>> Do people agree that it's worth the effort doing on now?
> 
> I don't want to impose unnecessary additional work on you, but my
> feeling is that a corrective release would be a good idea given that
> configuring using '../configure' isn't a totally crazy thing to do.
> 
> But would be nice to see what others think.
> 
> Thanks,
> Andrew
> 

I think it would be nice to have one, also to fix the x packet hiccup. Of
course, as long as that doesn't create substantial work for you on the
release.

Re: [ANNOUNCEMENT] GDB 16.1 released!

[Andrew Burgess via Gdb]

Joel Brobecker <brobecker@adacore.com> writes:

>> And we should decide what we want to do about:
>> 
>>   https://inbox.sourceware.org/gdb-patches/CAOp6jLYD0g-GUsx7jhO3g8H_4pHkB6dkh51cbyDT-5yMfQwu+A@mail.gmail.com
>> 
>> Before making any follow on release.
>
> Agreed!

Fix for the incompatible 'x' packet has now been pushed to the
gdb-16-branch.  I'm not aware of any other issues that need looking at.

Thanks,
Andrew

Re: [ANNOUNCEMENT] GDB 16.1 released!

[Joel Brobecker via Gdb]

> Fix for the incompatible 'x' packet has now been pushed to the
> gdb-16-branch.  I'm not aware of any other issues that need looking at.

Brilliant. We are on for a corrective release this weekend!

PS: I adjusted the 2 PRs to close them. My scripts will need that
    in order to build the changelog.

-- 
Joel