Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: GDB 9.0.90 available for testing
Date: Mon, 16 Dec 2019 17:23:00 -0000	[thread overview]
Message-ID: <83tv604239.fsf@gnu.org> (raw)
In-Reply-To: <20191211214745.E1CF0838D4@joel.gnat.com> (message from Joel	Brobecker on Wed, 11 Dec 2019 22:47:45 +0100 (CET))

> 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.


  parent reply	other threads:[~2019-12-16 17:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-11 21:47 Joel Brobecker
2019-12-11 21:56 ` Joel Brobecker
2019-12-16 17:23 ` Eli Zaretskii [this message]
2019-12-16 17:38   ` Simon Marchi
2019-12-16 17:50     ` Eli Zaretskii
2019-12-23  7:54       ` Joel Brobecker
2019-12-16 18:52   ` Christian Biesinger via gdb-patches
2019-12-16 19:18     ` Eli Zaretskii
2019-12-16 19:36       ` Pedro Alves
2019-12-16 19:57         ` Eli Zaretskii
2019-12-16 20:37           ` Christian Biesinger via gdb-patches
2019-12-16 20:38           ` Pedro Alves
2019-12-17 17:25             ` Eli Zaretskii
2019-12-18 20:19   ` Christian Biesinger via gdb-patches
2019-12-19 15:00     ` Eli Zaretskii
2019-12-19 19:17       ` Christian Biesinger via gdb-patches
2019-12-19 19:38         ` Eli Zaretskii
2019-12-23  7:43           ` Joel Brobecker
2019-12-23 17:32             ` Eli Zaretskii
2019-12-24  3:53               ` Joel Brobecker
2019-12-24 15:30                 ` Eli Zaretskii
2020-01-17 20:56                   ` Christian Biesinger via gdb-patches
2020-01-17 21:09                     ` Eli Zaretskii
2019-12-23  8:01   ` Joel Brobecker
2019-12-23 13:56     ` Eli Zaretskii
2019-12-24  3:49       ` Joel Brobecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83tv604239.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox