Iain Buclaw [Wed, 5 Feb 2020 11:45:13 +0000 (12:45 +0100)]
Make fputs_unfiltered use fputs_maybe_filtered
This patch redefines fputs_unfiltered in utils.c, with new behavior to
forward parameters to fputs_maybe_filtered. This makes
fputs_unfiltered identical to fputs_filtered, except filtering is
disabled.
Some callers of fputs_unfiltered have been updated to use ui_file_puts
where they were using other ui_file_* functions anyway for IO.
This fixes the problem I saw with \032\032post-prompt annotation being
flushed to stdout in the wrong order.
Iain Buclaw [Wed, 5 Feb 2020 11:25:09 +0000 (12:25 +0100)]
Make gdb_flush also flush the wrap buffer
This changes gdb_flush to also flush the internal wrap buffer. A few
places needed to continue using the previous approach, so this also
introduces ui_file_flush for those.
Implement '--enable-src-release-build' option and make src-release.sh use it
The generation of snapshots has been broken since we've disable
in-tree builds for GDB. Given that src-release.sh performs a build
before creating the release tarball, and that this build is performed
in-tree, the solution we found is to implement a new top-level
configure flag called '--enable-src-release-build' which disables the
in-tree build restriction, and then make src-release.sh use it.
ChangeLog:
2020-02-01 Sergio Durigan Junior <sergiodj@redhat.com>
Eli Zaretskii <eliz@gnu.org>
* configure.ac: Don't abort the build if trying to build GDB in tree
_and_ invoking with '--enable-src-release-build'.
* configure: Regenerate.
* src-release.sh (do_proto_toplev): Invoke 'configure' using
Eli Zaretskii [Sat, 1 Feb 2020 11:25:19 +0000 (15:25 +0400)]
libctf: compilation failure on MinGW due to missing errno values
This commit fixes a compilation failure in a couple of libctf files
due to the use of EOVERFLOW and ENOTSUP, which are not defined
when compiling on MinGW.
libctf/ChangeLog:
PR binutils/25155:
* ctf-create.c (EOVERFLOW): If not defined by system header,
redirect to ERANGE as a poor man's substitute.
* ctf-subr.c (ENOTSUP): If not defined, use ENOSYS instead.
This one is how Eli implemented it. I think this implementation
has a weakness in the following sense: If other units in libctf
start using those constants, we'll get the same error again.
Also, I'm wondering whether their use is documented as part of
the official libtcf API or not -- users might be writing code
that tests for these, and if the system doesn't support them,
how would they know what errno code to use in its place. This
argues for a having that information in one of libctf's header
files. I think it would be nice to have those in ctf-decls.h,
but I think we'll need to include <errno.h> in ctf-decls.h if
we decide to define those macros there.
Rather than second-guess what the CTF developers would prefer,
I'm starting by sending Eli's patch, to see what you guys think.
Hannes Domani [Tue, 28 Jan 2020 17:24:31 +0000 (18:24 +0100)]
Fix library segment-address for 64bit values
The address was written as a long value, but long is always a 32bit value
on Windows, which lead to truncated addresses.
The solution was to use paddress instead.
gdb/gdbserver/ChangeLog:
2020-01-28 Hannes Domani <ssbssa@yahoo.de>
* server.c (handle_qxfer_libraries): Write segment-address with
paddress.
Joel Brobecker [Fri, 17 Jan 2020 18:30:39 +0000 (19:30 +0100)]
Abort configure immediately if building GDB in tree
The move of gnulib to the top src directory is causing the GDB build
to break if configured in tree. We hope to lift that limitation at
some point but, in the meantime, this commit allows us to abort
the initial configure right away with a clear error message should
the user attempt to build in tree.
ChangeLog:
* configure.ac: Abort the build with an error if trying to build
GDB in tree.
* configure: Regenerate.
Recent MinGW versions require -lssp when using _FORTIFY_SOURCE, which
gdb does (in common-defs.h)
https://github.com/msys2/MINGW-packages/issues/5868#issuecomment-544107564
To avoid all the complications with checking for -lssp and making sure it's
linked statically, just don't define it.
gdb/ChangeLog:
2020-01-10 Christian Biesinger <cbiesinger@google.com>
* gdbsupport/common-defs.h: Don't define _FORTIFY_SOURCE on MinGW.
gdb: Don't allow annotations to influence what else GDB prints
A change was accidentally made that moved a call to do_gdb_disassembly
out of an if block guarded by 'if (source_print && sal.symtab)'. The
result was that if a user has 'set disassemble-next-line on' then the
backtrace would now include some disassembly of a few instructions in
each frame.
This change was not intentional, but was not spotted by any tests.
This commit restores the old behaviour and adds a test to ensure this
doesn't break again in the future.
Eli Zaretskii [Sun, 5 Jan 2020 05:50:27 +0000 (09:50 +0400)]
libctf: Add configure check for asprintf (for MinGW)
This commit fixes a compilation warning when compiling libctf
on MinGW:
libctf/ctf-dump.c:118:8: warning: implicit declaration of function
'asprintf'; did you mean 'vasprintf'? [-Wimplicit-function-declaration]
if (asprintf (&bit, " %lx: [slice 0x%x:0x%x]",
^~~~~~~~
vasprintf
MinGW doesn't provide that function, so we depend on the one provided
by libiberty. However, the declaration is guarded by HAVE_DECL_ASPRINTF,
which we do not have in libctf's config.h.
Eli Zaretskii [Mon, 23 Dec 2019 14:28:32 +0000 (16:28 +0200)]
Fix compilation of Readline on mingw.org's MinGW
readline/ChangeLog
2019-12-23 Eli Zaretskii <eliz@gnu.org>
* posixstat.h (S_IRGRP, S_IWGRP, S_IXGRP, S_IROTH, S_IWOTH)
(S_IXOTH, S_IRWXG, S_IRWXO): Define if undefined, even if S_IRWXU
is defined, because non-Posix systems may defined only the user
bits.
Tom Tromey [Wed, 18 Dec 2019 18:45:51 +0000 (11:45 -0700)]
Fix pthread_setname_np build error
My earlier patch to fix the pthread_setname_np build error on macOS
was incorrect. While the macOS man page claims that
pthread_setname_np returns void, in <pthread.h> it is actually
declared returning "int". I knew this earlier, but must have made
some mistake when preparing the patch for submission (perhaps when
removing the templates?).
This patch re-fixes the bug. I'm also applying it to the 9.1 branch.
Tested by building on macOS High Sierra.
gdb/ChangeLog
2019-12-18 Tom Tromey <tromey@adacore.com>
PR build/25268:
* gdbsupport/thread-pool.c (set_thread_name): Expect "int" return
type on macOS. Add comment.
Tom Tromey [Wed, 18 Dec 2019 15:03:01 +0000 (08:03 -0700)]
Fix build failure on macOS
PR build/25250 notes that the gdb 9 pre-release fails to build on
macOS, due to a name clash between field_kind::STRING and the STRING
token in ada-exp.y. I am not sure (I couldn't reproduce this myself),
but presumably this is due to differences caused by the version of
bison in use there.
This patch works around the problem by renaming the field_kind
enumerator. I chose to rename this one because it is used in
relatively few places -- it's just an implementation detail of the
style code.
This version also renames field_kind::SIGNED for consistency.
Let me know what you think. I intend to check this in on the gdb 9
branch as well.
Simon Marchi [Mon, 16 Dec 2019 21:30:49 +0000 (16:30 -0500)]
Fix double-free when creating more than one block in JIT debug info reader
A double-free happens when using a JIT debug info reader that creates
more than one block. In the loop that frees blocks in finalize_symtab,
at the very end, the gdb_block_iter_tmp variable is set initially, but
not changed as the loop advances. If we have two blocks, the first
iteration frees the first block, the second iteration frees the second
block, but the third iteration tries to free the second block again, as
gdb_block_iter_tmp keeps pointing on the second block.
Fix it by assigning the gdb_block_iter_tmp variable in the loop.
I have improved the jit-reader.exp test to cover this case, by adding a
second "JIT-ed" function and creating a block for it. I have renamed
the existing function to something I find a bit more descriptive. There
are no significant changes to jit-reader.exp itself, only updates
following the renaming. The important changes are in jithost.c
(generate a new function) and in jitreader.c (create a gdb_block for
that function).
This was found because of an ASan report:
$ ./gdb testsuite/outputs/gdb.base/jit-reader/jit-reader -ex "jit-reader-load /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/jit-reader/jitreader.so" -ex r
Reading symbols from testsuite/outputs/gdb.base/jit-reader/jit-reader...
Starting program: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/jit-reader/jit-reader
=================================================================
==1751048==ERROR: AddressSanitizer: heap-use-after-free on address 0x604000042eb8 at pc 0x5650ef8eec88 bp 0x7ffe52767290 sp 0x7ffe52767280
READ of size 8 at 0x604000042eb8 thread T0
#0 0x5650ef8eec87 in finalize_symtab /home/simark/src/binutils-gdb/gdb/jit.c:768
#1 0x5650ef8eef88 in jit_object_close_impl /home/simark/src/binutils-gdb/gdb/jit.c:797
#2 0x7fbbda986278 in read_debug_info /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jitreader.c:71
#3 0x5650ef8ef56b in jit_reader_try_read_symtab /home/simark/src/binutils-gdb/gdb/jit.c:850
#4 0x5650ef8effe3 in jit_register_code /home/simark/src/binutils-gdb/gdb/jit.c:948
#5 0x5650ef8f2c92 in jit_event_handler(gdbarch*) /home/simark/src/binutils-gdb/gdb/jit.c:1396
#6 0x5650ef0d137e in handle_jit_event /home/simark/src/binutils-gdb/gdb/breakpoint.c:5470
[snip]
0x604000042eb8 is located 40 bytes inside of 48-byte region [0x604000042e90,0x604000042ec0)
freed by thread T0 here:
#0 0x7fbbe57376b0 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:122
#1 0x5650ef8f350b in xfree<gdb_block> /home/simark/src/binutils-gdb/gdb/gdbsupport/common-utils.h:62
#2 0x5650ef8eeca9 in finalize_symtab /home/simark/src/binutils-gdb/gdb/jit.c:769
#3 0x5650ef8eef88 in jit_object_close_impl /home/simark/src/binutils-gdb/gdb/jit.c:797
#4 0x7fbbda986278 in read_debug_info /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jitreader.c:71
#5 0x5650ef8ef56b in jit_reader_try_read_symtab /home/simark/src/binutils-gdb/gdb/jit.c:850
#6 0x5650ef8effe3 in jit_register_code /home/simark/src/binutils-gdb/gdb/jit.c:948
#7 0x5650ef8f2c92 in jit_event_handler(gdbarch*) /home/simark/src/binutils-gdb/gdb/jit.c:1396
#8 0x5650ef0d137e in handle_jit_event /home/simark/src/binutils-gdb/gdb/breakpoint.c:5470
[snip]
previously allocated by thread T0 here:
#0 0x7fbbe5737cd8 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:153
#1 0x5650eef662f3 in xcalloc /home/simark/src/binutils-gdb/gdb/alloc.c:100
#2 0x5650ef8f34ea in xcnew<gdb_block> /home/simark/src/binutils-gdb/gdb/gdbsupport/poison.h:122
#3 0x5650ef8ed467 in jit_block_open_impl /home/simark/src/binutils-gdb/gdb/jit.c:557
#4 0x7fbbda98620a in read_debug_info /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jitreader.c:60
#5 0x5650ef8ef56b in jit_reader_try_read_symtab /home/simark/src/binutils-gdb/gdb/jit.c:850
#6 0x5650ef8effe3 in jit_register_code /home/simark/src/binutils-gdb/gdb/jit.c:948
#7 0x5650ef8f2c92 in jit_event_handler(gdbarch*) /home/simark/src/binutils-gdb/gdb/jit.c:1396
#8 0x5650ef0d137e in handle_jit_event /home/simark/src/binutils-gdb/gdb/breakpoint.c:5470
[snip]
gdb/ChangeLog:
* jit.c (finalize_symtab): Set gdb_block_iter_tmp in loop.
gdb/testsuite/ChangeLog:
* gdb.base/jit-reader.exp (jit_reader_test): Rename
jit_function_00 to jit_function_stack_mangle.
* gdb.base/jithost.c (jit_function_t): Rename to...
(jit_function_stack_mangle_t): ... this.
(jit_function_add_t): New typedef.
(jit_function_00_code): Rename to...
(jit_function_stack_mangle_code): ... this, make static.
(jit_function_add_code): New.
(main): Generate "add" function and call it. Adjust to changes
in jithost_abi.
* gdb.base/jithost.h (struct jithost_abi_bounds): New.
(struct jithost_abi) <begin, end>: Remove fields.
<object, function_stack_mangle, function_add>: New fields.
* gdb.base/jitreader.c (struct reader_state) <code_begin,
code_end>: Remove fields.
<func_stack_mangle>: New field.
(read_debug_info): Adjust to renaming, create block for "add"
function.
(read_sp, unwind_frame, get_frame_id): Adjust to other changes.
Update documentation for the default value of main set worker-threads
I forgot to update this documentation when I changed the default for
maint set worker-threads to be 0. This is a branch-only change, because
on trunk this has been changed back to unlimited.
gdb/doc/ChangeLog:
2019-12-15 Christian Biesinger <cbiesinger@google.com>
* gdb.texinfo (Maintenance Commands): Update documentation for
maint set worker-threads to say the default is 0.
Tom Tromey [Tue, 10 Dec 2019 21:16:19 +0000 (14:16 -0700)]
Fix build on macOS
PR build/25268 points out that the build fails on macOS, because on
macOS the "pthread_setname_np" function takes a single argument.
This patch fixes the problem, by introducing a new adapter function
that handles both styles of pthread_setname_np.
This change also meant moving the pthread_setname_np call to the
thread function, because macOS only permits setting the name of the
current thread. This means that there can be a brief window when gdb
will see the wrong name; but I think this is a minor concern.
Tested by rebuilding on x86-64 Fedora 30, and on macOS High Sierra.
On Linux I also debugged gdb to ensure that the thread names are still
set correctly.
gdb/ChangeLog
2019-12-11 Tom Tromey <tromey@adacore.com>
Tom Tromey [Wed, 11 Dec 2019 14:58:46 +0000 (07:58 -0700)]
Fix the build after bfd_get_signed_8 change
A recent commit changed bfd_get_signed_8 to extend the result to a
bfd_signed_vma. This caused a compiler error in one spot in my
--enable-targets=all gdb build, where the result of bfd_get_signed_8
was passed to printf.
This patch fixes the build. Tested by rebuilding.
gdb/ChangeLog
2019-12-11 Tom Tromey <tromey@adacore.com>
* fbsd-tdep.c (fbsd_core_info_proc_status): Cast result of
bfd_get_signed_8.