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