GDB 9.0.90 available for testing

GDB 9.0.90 available for testing

[Joel Brobecker]

Hello,

I have just finished creating the gdb-9.0.90 pre-release.
It is available for download at the following location:

    ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-9.0.90.tar.xz

A gzip'ed version is also available: gdb-9.0.90.tar.gz.

Please give it a test if you can and report any problems you might find.

On behalf of all the GDB contributors, thank you!
-- 
Joel Brobecker

Re: GDB 9.0.90 available for testing

[Joel Brobecker]

> I have just finished creating the gdb-9.0.90 pre-release.
> It is available for download at the following location:
> 
>     ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-9.0.90.tar.xz
> 
> A gzip'ed version is also available: gdb-9.0.90.tar.gz.
> 
> Please give it a test if you can and report any problems you might find.

There was something I meant to add, and didn't because this email
was automatically generated by my scripts:

    When building GDB, the build must be done out-of-tree.
    In other words:

        $ tar xf gdb-9.0.90.tar.xz
        $ mkdir build_area
        $ cd build_area
        $ ../gdb-9.0.90/configure [xxx]
        $ make [-j N]
        $ make install

    Trying to unpack, cd to the unpacked sources, and build from
    there will not work. You will get an error about gnulib already
    being configured.

    This is a known issue, which should get fixed after we move
    the gdbsupport and then gdbserver directories to toplevel.

And I wanted to repeat, because this release is really all about
the work done by all the contributors:

> On behalf of all the GDB contributors, thank you!

Cheers!
-- 
Joel

Re: GDB 9.0.90 available for testing

[Eli Zaretskii]

> From: Joel Brobecker <brobecker@adacore.com>
> Date: Wed, 11 Dec 2019 22:47:45 +0100 (CET)
> 
> 
>     ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-9.0.90.tar.xz
> 
> A gzip'ed version is also available: gdb-9.0.90.tar.gz.
> 
> Please give it a test if you can and report any problems you might find.

I've built this with mingw.org's MinGW, using GCC 8.3.0 and Binutils
2.33, and found the following issues:

1. The produced gdb.exe and gdbserver.exe depend on the libstdc++ and
   libgcc DLLs.  I thought this was supposed to be prevented, or did I
   dream?  Should I force -static-libgcc etc. switches via
   configure-time variables?

2. readline/colors.c fails to compile because it uses the likes of
   S_IXGRP and S_IXOTH, which aren't defined in MinGW.  The solution
   is to patch readline/posixstat.h to add the missing defines (it
   tries to do so, but makes assumptions that don't do a perfect job).

3. When configure runs in gdb/, it displays a warning thusly:

     checking for pthread-config... no
     /d/usr/eli/utils/gdb-9.0.90/gdb/configure: line 14342: test: =: unary operator expected

   It is triggered by this line:

     if test $gdb_cv_cxx_std_thread = yes; then

   but I have no idea what's wrong with this.  Any hints?

4. libctf fails to compile due to 3 compilation errors.  I already
   found these problems when building Binutils 2.33 and reported them
   on Bugzilla (https://sourceware.org/bugzilla/show_bug.cgi?id=25155),
   but it seems nothing was done about that in the meantime.

5. A compilation warning in gdb/, which wasn't there in GDB 8.3:

       CXX    record-btrace.o
     In file included from ../../gdb-9.0.90/gdb/exceptions.h:23,
		      from ../../gdb-9.0.90/gdb/utils.h:24,
		      from ../../gdb-9.0.90/gdb/defs.h:652,
		      from ../../gdb-9.0.90/gdb/record-btrace.c:22:
     ../../gdb-9.0.90/gdb/ui-out.h: In function 'void btrace_insn_history(ui_out*, const btrace_thread_info*, const btrace_insn_iterator*, const btrace_insn_iterator*, gdb_disassembly_flags)':
     ../../gdb-9.0.90/gdb/ui-out.h:349:18: warning: 'asm_list.ui_out_emit_type<(ui_out_type)1>::m_uiout' may be used uninitialized in this function [-Wmaybe-uninitialized]
	  m_uiout->end (Type);
	  ~~~~~~~~~~~~~^~~~~~
     ../../gdb-9.0.90/gdb/record-btrace.c:779:35: note: 'asm_list.ui_out_emit_type<(ui_out_type)1>::m_uiout' was declared here
	gdb::optional<ui_out_emit_list> asm_list;
					^~~~~~~~

   Any suggestions how to fix this?

6. One last comment about "gdb -tui": while stepping with "next"
   through a program (in this case, GDB's only binary), sometimes the
   source window becomes blank and shows only "No source" in it.  This
   happens when the command windo shows some DWARF-related error
   message.  Is this expected?  I don't think I saw this in previous
   versions of GDB.

Please tell me how to go about fixing these problems on the release
branch.  Do we still maintain our separate copy of Readline, or do I
need to report to its upstream maintainer?  And what to do about
libctf? how can I speed up the handling of those problems upstream?

Thanks.

Re: GDB 9.0.90 available for testing

[Simon Marchi]

On 2019-12-16 12:22 p.m., Eli Zaretskii wrote:
> 3. When configure runs in gdb/, it displays a warning thusly:
> 
>      checking for pthread-config... no
>      /d/usr/eli/utils/gdb-9.0.90/gdb/configure: line 14342: test: =: unary operator expected
> 
>    It is triggered by this line:
> 
>      if test $gdb_cv_cxx_std_thread = yes; then
> 
>    but I have no idea what's wrong with this.  Any hints?

This is most likely due to the variable gdb_cv_cxx_std_thread being empty.  See, we get the
same error message if we do this with bash:

bash$ test = yes
bash: test: =: unary operator expected

We either need to

(1) make sure gdb_cv_cxx_std_thread is set to something, regardless of the code path taken
(2) wrap $db_cv_cxx_std_thread in quotes

Even if we do (1), it's good practice to do (2), in case the variable has spaces in it.

That code is in gdbsupport/common.m4.

Simon

Re: GDB 9.0.90 available for testing

[Eli Zaretskii]

> Cc: gdb-patches@sourceware.org
> From: Simon Marchi <simark@simark.ca>
> Date: Mon, 16 Dec 2019 12:38:44 -0500
> 
> We either need to
> 
> (1) make sure gdb_cv_cxx_std_thread is set to something, regardless of the code path taken
> (2) wrap $db_cv_cxx_std_thread in quotes
> 
> Even if we do (1), it's good practice to do (2), in case the variable has spaces in it.
> 
> That code is in gdbsupport/common.m4.

Right.  I can fix common.m4, but I cannot regenerate configure, as I
don't have the correct versions of autotools installed.  Should I fix
common.m4, or would someone else want to do that?

Thanks.

Re: GDB 9.0.90 available for testing

[Joel Brobecker]

> > (1) make sure gdb_cv_cxx_std_thread is set to something, regardless of the code path taken
> > (2) wrap $db_cv_cxx_std_thread in quotes
> > 
> > Even if we do (1), it's good practice to do (2), in case the variable has spaces in it.
> > 
> > That code is in gdbsupport/common.m4.
> 
> Right.  I can fix common.m4, but I cannot regenerate configure, as I
> don't have the correct versions of autotools installed.  Should I fix
> common.m4, or would someone else want to do that?

One almost never has the correct versions of autotools pre-installed.
The distros tend to ship something close to the latest version that
was available at the time, and it rarely matches the version that
we are expected to use for each project. The only way I've found to
have the correct version was to build the various versions myself,
and update the PATH accordingly each time I need a set. More effort
than "it-just-works(tm)", but it's really not that bad. We don't change
the auto-tools versions all that often, and building those tools
just takes a few minutes each.

So, my recommendation if you want to control the pace at which this
is fixed, is to build your own set of auto-tools. On my end, I don't
think I'll have much time during the coming weeks, unfortunately.

-- 
Joel

Re: GDB 9.0.90 available for testing

[Christian Biesinger via gdb-patches]

On Mon, Dec 16, 2019 at 11:23 AM Eli Zaretskii <eliz@gnu.org> wrote:
> 2. readline/colors.c fails to compile because it uses the likes of
>    S_IXGRP and S_IXOTH, which aren't defined in MinGW.  The solution
>    is to patch readline/posixstat.h to add the missing defines (it
>    tries to do so, but makes assumptions that don't do a perfect job).

I don't see either of those two used in colors.c?

> 5. A compilation warning in gdb/, which wasn't there in GDB 8.3:
>
>        CXX    record-btrace.o
>      In file included from ../../gdb-9.0.90/gdb/exceptions.h:23,
>                       from ../../gdb-9.0.90/gdb/utils.h:24,
>                       from ../../gdb-9.0.90/gdb/defs.h:652,
>                       from ../../gdb-9.0.90/gdb/record-btrace.c:22:
>      ../../gdb-9.0.90/gdb/ui-out.h: In function 'void btrace_insn_history(ui_out*, const btrace_thread_info*, const btrace_insn_iterator*, const btrace_insn_iterator*, gdb_disassembly_flags)':
>      ../../gdb-9.0.90/gdb/ui-out.h:349:18: warning: 'asm_list.ui_out_emit_type<(ui_out_type)1>::m_uiout' may be used uninitialized in this function [-Wmaybe-uninitialized]
>           m_uiout->end (Type);
>           ~~~~~~~~~~~~~^~~~~~
>      ../../gdb-9.0.90/gdb/record-btrace.c:779:35: note: 'asm_list.ui_out_emit_type<(ui_out_type)1>::m_uiout' was declared here
>         gdb::optional<ui_out_emit_list> asm_list;
>                                         ^~~~~~~~
>
>    Any suggestions how to fix this?

I see this on Linux too, fwiw. I assumed everyone saw it...

> Please tell me how to go about fixing these problems on the release
> branch.  Do we still maintain our separate copy of Readline, or do I
> need to report to its upstream maintainer?  And what to do about
> libctf? how can I speed up the handling of those problems upstream?

I've had some success in sending a bug report/patch to upstream
readline. Not sure about ctf.

Christian

Re: GDB 9.0.90 available for testing

[Eli Zaretskii]

> From: Christian Biesinger <cbiesinger@google.com>
> Date: Mon, 16 Dec 2019 12:51:28 -0600
> Cc: Joel Brobecker <brobecker@adacore.com>, gdb-patches <gdb-patches@sourceware.org>
> 
> On Mon, Dec 16, 2019 at 11:23 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > 2. readline/colors.c fails to compile because it uses the likes of
> >    S_IXGRP and S_IXOTH, which aren't defined in MinGW.  The solution
> >    is to patch readline/posixstat.h to add the missing defines (it
> >    tries to do so, but makes assumptions that don't do a perfect job).
> 
> I don't see either of those two used in colors.c?

It uses S_IXUGO, which is defined via those.  It also uses S_IWOTH.

> > Please tell me how to go about fixing these problems on the release
> > branch.  Do we still maintain our separate copy of Readline, or do I
> > need to report to its upstream maintainer?  And what to do about
> > libctf? how can I speed up the handling of those problems upstream?
> 
> I've had some success in sending a bug report/patch to upstream
> readline. Not sure about ctf.

The questions is whether I fix this in our copy independently of
reporting to upstream, or report upstream, and then someone updates
our copy from upstream.

Thanks.

Re: GDB 9.0.90 available for testing

[Pedro Alves]

On 12/16/19 7:17 PM, Eli Zaretskii wrote:
>> I've had some success in sending a bug report/patch to upstream
>> readline. Not sure about ctf.
> The questions is whether I fix this in our copy independently of
> reporting to upstream, or report upstream, and then someone updates
> our copy from upstream.

I don't think there's an upstream.  I mean, I think libctf is maintained
in the binutils-gdb repo.  That it's more of a binutils project than
a gdb project.  See top level MAINTAINERS file:

 bfd/; binutils/; elfcpp/; gas/; gold/; gprof/; ld/; opcodes/; cpu/;
 libctf/; BFD's and libctf's parts of include/

        binutils: http://sourceware.org/binutils/
        Patches to binutils@sourceware.org.
        Please notify the following of any interface changes:
                gdb-patches@sourceware.org

Thanks,
Pedro Alves

Re: GDB 9.0.90 available for testing

[Eli Zaretskii]

> Cc: brobecker@adacore.com, gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Mon, 16 Dec 2019 19:36:04 +0000
> 
> I don't think there's an upstream.  I mean, I think libctf is maintained
> in the binutils-gdb repo.  That it's more of a binutils project than
> a gdb project.  See top level MAINTAINERS file:
> 
>  bfd/; binutils/; elfcpp/; gas/; gold/; gprof/; ld/; opcodes/; cpu/;
>  libctf/; BFD's and libctf's parts of include/
> 
>         binutils: http://sourceware.org/binutils/
>         Patches to binutils@sourceware.org.
>         Please notify the following of any interface changes:
>                 gdb-patches@sourceware.org

So whom do I pester about these problems?  They were left uncommented
on Bugzilla since the beginning of November.

Or do I just push the changes?

Re: GDB 9.0.90 available for testing

[Christian Biesinger via gdb-patches]

On Mon, Dec 16, 2019 at 1:57 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Cc: brobecker@adacore.com, gdb-patches@sourceware.org
> > From: Pedro Alves <palves@redhat.com>
> > Date: Mon, 16 Dec 2019 19:36:04 +0000
> >
> > I don't think there's an upstream.  I mean, I think libctf is maintained
> > in the binutils-gdb repo.  That it's more of a binutils project than
> > a gdb project.  See top level MAINTAINERS file:
> >
> >  bfd/; binutils/; elfcpp/; gas/; gold/; gprof/; ld/; opcodes/; cpu/;
> >  libctf/; BFD's and libctf's parts of include/
> >
> >         binutils: http://sourceware.org/binutils/
> >         Patches to binutils@sourceware.org.
> >         Please notify the following of any interface changes:
> >                 gdb-patches@sourceware.org
>
> So whom do I pester about these problems?  They were left uncommented
> on Bugzilla since the beginning of November.
>
> Or do I just push the changes?

Did you email the patches to binutils@sourceware.org yet?

Christian

Re: GDB 9.0.90 available for testing

[Pedro Alves]

On 12/16/19 7:57 PM, Eli Zaretskii wrote:
>> Cc: brobecker@adacore.com, gdb-patches@sourceware.org
>> From: Pedro Alves <palves@redhat.com>
>> Date: Mon, 16 Dec 2019 19:36:04 +0000
>>
>> I don't think there's an upstream.  I mean, I think libctf is maintained
>> in the binutils-gdb repo.  That it's more of a binutils project than
>> a gdb project.  See top level MAINTAINERS file:
>>
>>  bfd/; binutils/; elfcpp/; gas/; gold/; gprof/; ld/; opcodes/; cpu/;
>>  libctf/; BFD's and libctf's parts of include/
>>
>>         binutils: http://sourceware.org/binutils/
>>         Patches to binutils@sourceware.org.
>>         Please notify the following of any interface changes:
>>                 gdb-patches@sourceware.org
> 
> So whom do I pester about these problems?  They were left uncommented
> on Bugzilla since the beginning of November.

I'd reach out to Nick Alcock, CCing binutils.

Thanks,
Pedro Alves

Re: GDB 9.0.90 available for testing

[Eli Zaretskii]

> Cc: cbiesinger@google.com, brobecker@adacore.com, gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Mon, 16 Dec 2019 20:38:01 +0000
> 
> > So whom do I pester about these problems?  They were left uncommented
> > on Bugzilla since the beginning of November.
> 
> I'd reach out to Nick Alcock, CCing binutils.

Thanks, done.

Re: GDB 9.0.90 available for testing

[Christian Biesinger via gdb-patches]

On Mon, Dec 16, 2019 at 11:23 AM Eli Zaretskii <eliz@gnu.org> wrote:
> 2. readline/colors.c fails to compile because it uses the likes of
>    S_IXGRP and S_IXOTH, which aren't defined in MinGW.  The solution
>    is to patch readline/posixstat.h to add the missing defines (it
>    tries to do so, but makes assumptions that don't do a perfect job).

FWIW, I've reported this at https://osdn.net/projects/mingw/ticket/39856

I would suggest patching readline locally and also sending a patch
upstream; that's what I did in
http://sourceware-org.1504.n7.nabble.com/PATCH-readline-Fix-compilation-on-MinGW-td585030.html

Christian

Re: GDB 9.0.90 available for testing

[Eli Zaretskii]

> From: Christian Biesinger <cbiesinger@google.com>
> Date: Wed, 18 Dec 2019 14:19:18 -0600
> Cc: Joel Brobecker <brobecker@adacore.com>, gdb-patches <gdb-patches@sourceware.org>
> 
> On Mon, Dec 16, 2019 at 11:23 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > 2. readline/colors.c fails to compile because it uses the likes of
> >    S_IXGRP and S_IXOTH, which aren't defined in MinGW.  The solution
> >    is to patch readline/posixstat.h to add the missing defines (it
> >    tries to do so, but makes assumptions that don't do a perfect job).
> 
> FWIW, I've reported this at https://osdn.net/projects/mingw/ticket/39856

Thanks.

> I would suggest patching readline locally and also sending a patch
> upstream; that's what I did in
> http://sourceware-org.1504.n7.nabble.com/PATCH-readline-Fix-compilation-on-MinGW-td585030.html

I've now reported the problem to Readline developers.  Should I go
ahead and patch our local copy, or should I wait for the Readline
developers to respond?

Re: GDB 9.0.90 available for testing

[Christian Biesinger via gdb-patches]

On Thu, Dec 19, 2019 at 9:00 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Christian Biesinger <cbiesinger@google.com>
> > Date: Wed, 18 Dec 2019 14:19:18 -0600
> > Cc: Joel Brobecker <brobecker@adacore.com>, gdb-patches <gdb-patches@sourceware.org>
> >
> > On Mon, Dec 16, 2019 at 11:23 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > > 2. readline/colors.c fails to compile because it uses the likes of
> > >    S_IXGRP and S_IXOTH, which aren't defined in MinGW.  The solution
> > >    is to patch readline/posixstat.h to add the missing defines (it
> > >    tries to do so, but makes assumptions that don't do a perfect job).
> >
> > FWIW, I've reported this at https://osdn.net/projects/mingw/ticket/39856
>
> Thanks.
>
> > I would suggest patching readline locally and also sending a patch
> > upstream; that's what I did in
> > http://sourceware-org.1504.n7.nabble.com/PATCH-readline-Fix-compilation-on-MinGW-td585030.html
>
> I've now reported the problem to Readline developers.  Should I go
> ahead and patch our local copy, or should I wait for the Readline
> developers to respond?

Looks like Chet acknowledged the patch:
https://lists.gnu.org/archive/html/bug-readline/2019-12/msg00003.html

Given the unusual way the readline git repository is managed, probably
best to patch it locally for now? (not like I have any authority
here...)

Christian

Re: GDB 9.0.90 available for testing

[Eli Zaretskii]

> From: Christian Biesinger <cbiesinger@google.com>
> Date: Thu, 19 Dec 2019 13:17:18 -0600
> Cc: Joel Brobecker <brobecker@adacore.com>, gdb-patches <gdb-patches@sourceware.org>
> 
> > I've now reported the problem to Readline developers.  Should I go
> > ahead and patch our local copy, or should I wait for the Readline
> > developers to respond?
> 
> Looks like Chet acknowledged the patch:
> https://lists.gnu.org/archive/html/bug-readline/2019-12/msg00003.html

Yes.

> Given the unusual way the readline git repository is managed, probably
> best to patch it locally for now? (not like I have any authority
> here...)

Joel, could you please advise?

Re: GDB 9.0.90 available for testing

[Joel Brobecker]

> > > I've now reported the problem to Readline developers.  Should I go
> > > ahead and patch our local copy, or should I wait for the Readline
> > > developers to respond?
> > 
> > Looks like Chet acknowledged the patch:
> > https://lists.gnu.org/archive/html/bug-readline/2019-12/msg00003.html
> 
> Yes.
> 
> > Given the unusual way the readline git repository is managed, probably
> > best to patch it locally for now? (not like I have any authority
> > here...)
> 
> Joel, could you please advise?

Of course! :-)

Just for clarity and completeness, I'll mention that this is more
about our handling of readline inside GDB than release management.
But I've had to deal with readline issues before, so I think I know
the process, which is basically:

  - Patch locally, and submit the patch to readline;

  - Keep track of the patch submission on the readline end;
    when a patch is applied, if different from the one accepted
    upstream, then undo our local patch, and apply the one from
    upstream. This ensures the one applied upstream doesn't introduce
    some issues we haven't seen during review.

Another version of the process is when the fix was already applied
upstream. In that case, no need to submit anything, since it's already
fixed. We just backport the fix from upstream into GDB's version
of readline.

-- 
Joel

Re: GDB 9.0.90 available for testing

[Eli Zaretskii]

> Date: Mon, 23 Dec 2019 11:43:46 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Christian Biesinger <cbiesinger@google.com>, gdb-patches@sourceware.org
> 
>   - Patch locally, and submit the patch to readline;

This part is now done.

>   - Keep track of the patch submission on the readline end;

How does one do that?  I looked at the Readline's Git repository, but
couldn't find the patch there, and didn't understand the branch
arrangement.  Perhaps Chet didn't yet push the changes?  Or am I
missing something?

Thanks.

Re: GDB 9.0.90 available for testing

[Joel Brobecker]

> >   - Patch locally, and submit the patch to readline;
> 
> This part is now done.

Excellent, thank you.

> >   - Keep track of the patch submission on the readline end;
> 
> How does one do that?  I looked at the Readline's Git repository, but
> couldn't find the patch there, and didn't understand the branch
> arrangement.  Perhaps Chet didn't yet push the changes?  Or am I
> missing something?

That one is a little tougher. When I read Chet's message, I thought
it was a little ambiguous, but the way I read it was that he was
only acknowledging the receipt of the report and patch, so he hadn't
had a chance to review and apply it. What I would do is ask him
if he could let us know when it is reviewed and (hopefully) applied.

If he forgets, that's not a huge deal, but we basically expose
ourselves to facing that same issue again at the next readline
upgrade. We could be even more proactive, but I don't think it
would be worth the effort.

-- 
Joel

Re: GDB 9.0.90 available for testing

[Eli Zaretskii]

> Date: Tue, 24 Dec 2019 07:53:15 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: cbiesinger@google.com, gdb-patches@sourceware.org
> 
> > >   - Keep track of the patch submission on the readline end;
> > 
> > How does one do that?  I looked at the Readline's Git repository, but
> > couldn't find the patch there, and didn't understand the branch
> > arrangement.  Perhaps Chet didn't yet push the changes?  Or am I
> > missing something?
> 
> That one is a little tougher. When I read Chet's message, I thought
> it was a little ambiguous, but the way I read it was that he was
> only acknowledging the receipt of the report and patch, so he hadn't
> had a chance to review and apply it. What I would do is ask him
> if he could let us know when it is reviewed and (hopefully) applied.
> 
> If he forgets, that's not a huge deal, but we basically expose
> ourselves to facing that same issue again at the next readline
> upgrade. We could be even more proactive, but I don't think it
> would be worth the effort.

OK, thanks.  I will try to keep an eye on Readline.

Re: GDB 9.0.90 available for testing

[Christian Biesinger via gdb-patches]

On Tue, Dec 24, 2019 at 10:30 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Date: Tue, 24 Dec 2019 07:53:15 +0400
> > From: Joel Brobecker <brobecker@adacore.com>
> > Cc: cbiesinger@google.com, gdb-patches@sourceware.org
> >
> > > >   - Keep track of the patch submission on the readline end;
> > >
> > > How does one do that?  I looked at the Readline's Git repository, but
> > > couldn't find the patch there, and didn't understand the branch
> > > arrangement.  Perhaps Chet didn't yet push the changes?  Or am I
> > > missing something?
> >
> > That one is a little tougher. When I read Chet's message, I thought
> > it was a little ambiguous, but the way I read it was that he was
> > only acknowledging the receipt of the report and patch, so he hadn't
> > had a chance to review and apply it. What I would do is ask him
> > if he could let us know when it is reviewed and (hopefully) applied.
> >
> > If he forgets, that's not a huge deal, but we basically expose
> > ourselves to facing that same issue again at the next readline
> > upgrade. We could be even more proactive, but I don't think it
> > would be worth the effort.
>
> OK, thanks.  I will try to keep an eye on Readline.

Looks like this landed in readline:
http://git.savannah.gnu.org/cgit/readline.git/diff/posixstat.h?h=devel&id=e09431eaf2de3c3ac289a42c85a760ec549f634e

I haven't checked if there are any changes relative to Eli's patch.

Christian

Re: GDB 9.0.90 available for testing

[Eli Zaretskii]

> From: Christian Biesinger <cbiesinger@google.com>
> Date: Fri, 17 Jan 2020 15:38:46 -0500
> Cc: Joel Brobecker <brobecker@adacore.com>, gdb-patches <gdb-patches@sourceware.org>
> 
> Looks like this landed in readline:
> http://git.savannah.gnu.org/cgit/readline.git/diff/posixstat.h?h=devel&id=e09431eaf2de3c3ac289a42c85a760ec549f634e
> 
> I haven't checked if there are any changes relative to Eli's patch.

It's exactly the patch I sent.

Thanks.

Re: GDB 9.0.90 available for testing

[Joel Brobecker]

> 1. The produced gdb.exe and gdbserver.exe depend on the libstdc++ and
>    libgcc DLLs.  I thought this was supposed to be prevented, or did I
>    dream?  Should I force -static-libgcc etc. switches via
>    configure-time variables?

If you build with GNU Highligh support (used to highlight the sources),
then you need to use the shared libstdc++. So, if you need GDB to use
the static version of the libgcc/libstdc++, you'll need to configure
GDB explicitly, via:

    --with-static-standard-libraries
    --disable-source-highlight

-- 
Joel

Re: GDB 9.0.90 available for testing

[Eli Zaretskii]

> Date: Mon, 23 Dec 2019 12:01:16 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sourceware.org
> 
> > 1. The produced gdb.exe and gdbserver.exe depend on the libstdc++ and
> >    libgcc DLLs.  I thought this was supposed to be prevented, or did I
> >    dream?  Should I force -static-libgcc etc. switches via
> >    configure-time variables?
> 
> If you build with GNU Highligh support (used to highlight the sources),
> then you need to use the shared libstdc++. So, if you need GDB to use
> the static version of the libgcc/libstdc++, you'll need to configure
> GDB explicitly, via:
> 
>     --with-static-standard-libraries
>     --disable-source-highlight

I don't think this is related to source-highlight in my case, because
I have only the static libsource-highlight.a library installed.  (I
didn't install the shared library version precisely because it depends
on libstdc++ DLL.)

I think Pedro explained why I suddenly have the dependency on libstc++
DLL where I didn't with previous GDB versions: we no longer inherit
-static-libstdc++ switch from GCC.  It now has to be requested
explicitly, via --with-static-standard-libraries.

Re: GDB 9.0.90 available for testing

[Joel Brobecker]

> I don't think this is related to source-highlight in my case, because
> I have only the static libsource-highlight.a library installed.  (I
> didn't install the shared library version precisely because it depends
> on libstdc++ DLL.)
> 
> I think Pedro explained why I suddenly have the dependency on libstc++
> DLL where I didn't with previous GDB versions: we no longer inherit
> -static-libstdc++ switch from GCC.  It now has to be requested
> explicitly, via --with-static-standard-libraries.

Understood. I misread some of my notes...

-- 
Joel