Philippe Waroquiers [Sat, 13 Apr 2019 07:13:53 +0000 (09:13 +0200)]
Fix GDB 8.3 regression crash when registers cannot be modified.
This crash was detected when using GDB with the valgrind gdbserver.
To reproduce:
valgrind sleep 10000
In another window:
gdb
target remote | vgdb
p printf("make sleep print something\n")
=>
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
Aborted
The problem is that the valgrind gdbserver does not allow to change
registers when the inferior is blocked in a system call.
GDB then raises an exception. The exception causes the destructor
of
typedef std::unique_ptr<infcall_suspend_state, infcall_suspend_state_deleter>
infcall_suspend_state_up;
to be called. This destructor itself tries to restore the value of
the registers, and fails similarly. We must catch the exception in
the destructor to avoid crashing GDB.
If the destructor encounters a problem, no warning is produced if
there is an uncaught exception, as in this case, the user will already
be informed of a problem via this exception.
With this change, no crash anymore, and all the valgrind 3.15 tests
pass succesfully.
Note: when this patch is approved, I will push an equivalent patch
on master, but with TRY/CATCH/e.message () replaced by
try/catch/e.what ().
gdb/ChangeLog
2019-04-19 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* inferior.h (struct infcall_suspend_state_deleter):
Catch exception in destructor to avoid crash.
GDB Administrator [Fri, 19 Apr 2019 00:00:59 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Thu, 18 Apr 2019 00:00:54 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Wed, 17 Apr 2019 00:00:55 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Tue, 16 Apr 2019 00:01:00 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Mon, 15 Apr 2019 00:00:53 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Sun, 14 Apr 2019 00:01:33 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Sat, 13 Apr 2019 00:01:38 +0000 (00:01 +0000)]
Automatic date update in version.in
Eli Zaretskii [Fri, 12 Apr 2019 12:35:57 +0000 (15:35 +0300)]
Another fix for GDB styling
gdb/ChangeLog:
2019-04-12 Eli Zaretskii <eliz@gnu.org>
* utils.c (prompt_for_continue): Don't restore the styling at the
end, as applied_style has the wrong value. This fixes styling in
long lists of file names that are interrupted by the "Continue?"
prompt.
(cherry picked from commit
51196bbc5618a3741bd7bbed01ac76b25a2e6f9c)
GDB Administrator [Fri, 12 Apr 2019 00:01:19 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Thu, 11 Apr 2019 00:01:23 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Wed, 10 Apr 2019 00:01:14 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Tue, 9 Apr 2019 00:01:04 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Mon, 8 Apr 2019 00:01:11 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Sun, 7 Apr 2019 00:02:24 +0000 (00:02 +0000)]
Automatic date update in version.in
GDB Administrator [Sat, 6 Apr 2019 00:00:47 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Fri, 5 Apr 2019 00:00:51 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Thu, 4 Apr 2019 00:00:55 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Wed, 3 Apr 2019 00:00:52 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Tue, 2 Apr 2019 00:01:26 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Mon, 1 Apr 2019 00:01:37 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Sun, 31 Mar 2019 00:02:08 +0000 (00:02 +0000)]
Automatic date update in version.in
GDB Administrator [Sat, 30 Mar 2019 00:01:16 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Fri, 29 Mar 2019 00:01:25 +0000 (00:01 +0000)]
Automatic date update in version.in
Pedro Alves [Thu, 28 Mar 2019 17:33:13 +0000 (12:33 -0500)]
Fix testsuite hangs when gdb_test_multiple body errors out
This commit fixes a regression in the testsuite itself, triggered by
errors being raised from within gdb_test_multiple, originally reported
by Pedro Franco de Carvalho's at
<https://sourceware.org/ml/gdb-patches/2019-03/msg00160.html>. Parts
of the commit message are based on his report.
This started happening due to a commit that was introduced recently,
and it can cause the testsuite to hang.
The commit that triggers this is:
fe1a5cad302b5535030cdf62895e79512713d738
[gdb/testsuite] Log wait status on process no longer exists error
That commit introduces a new "eof" block in gdb_test_multiple. That
is not incorrect itself, but dejagnu's remote_expect is picking that
block as the "default" action when an error is raised from within the
commands inside a call to gdb_test_multiple:
# remote_expect works basically the same as standard expect, but it
# also takes care of getting the file descriptor from the specified
# host and also calling the timeout/eof/default section if there is an
# error on the expect call.
#
proc remote_expect { board timeout args } {
I find that "feature" surprising, and I don't really know why it
exists, but this means that the eof section that remote_expect picks
as the error block can be executed even when there was no actual eof
and the GDB process is still running, so the wait introduced in the
commit that tries to get the exit status of GDB hangs forever, while
GDB itself waits for input.
This only happens when there are internal testsuite errors (not
testcase failures). This can be reproduced easily with a testcase
such as:
gdb_start
gdb_test_multiple "show version" "show version" {
-re ".*" {
error "forced error"
}
}
I think that working around this in GDB is useful so that the
testsuite doesn't hang in these cases.
Adding an empty "default" block at the end of the expect body in
gdb_test_multiple doesn't work, because dejagnu gives preference to
"eof" blocks:
if { $x eq "eof" } {
set save_next 1
} elseif { $x eq "default" || $x eq "timeout" } {
if { $error_sect eq "" } {
set save_next 1
}
}
And we do have "eof" blocks. So we need to make sure that the last
"eof" block is safe to use as the default error block. It's also
pedantically incorrect to print
"ERROR: Process no longer exists"
which is what we'd get if the last eof block we have was selected
(more below on this).
So this commit solves this by appending an "eof" with an empty
spawn_id list, so that it won't ever match.
Now, why is the first "eof" block selected today as the error block,
instead of the last one?
The reason is that remote_expect, while parsing the body to select the
default block to execute after an error, is affected by the comments
in the body (since they are also parsed).
If this comment in gdb_test_multiple
# patterns below apply to any spawn id specified.
is changed to
# The patterns below apply to any spawn id specified.
then the second eof block is selected and there is no hang.
Any comment at that same place with an even number of tokens also
works.
This is IMO a coincidence caused by how comments work in TCL.
Comments should only appear in places where a command can appear. And
here, remote_expect is parsing a list of options, not commands, so
it's not unreasonable to not parse comments, similarly to how this:
set a_list {
an_element
# another_element
}
results in a list with three elements, not one element.
The fact that comments with an even number of tokens work is just a
coincidence of how remote_expect's little state machine is
implemented.
I thought we could solve this by stripping out comment lines in
gdb_expect, but I didn't find an easy way to do that. Particularly, a
couple naive approaches I tried run into complications. For example,
we have gdb_test calls with regular expressions that include sequences
like "\r\n#", and by the time we get to gdb_expect, the \r\n have
already been expanded to a real newline, so just splitting the whole
body at newline boundaries, looking for lines that start with #
results in incorrectly stripping out half of the gdb_text regexp. I
think it's better (at least in this commit), to move the comments out
of the list, because it's much simpler and risk free.
gdb/testsuite/ChangeLog:
2019-03-25 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_test_multiple): Split appends to $code and
move comments outside list. Append '-i "" eof' section.
(cherry picked from commit
9a93502fa81734d39f213ccb33b497bc40e1423d)
GDB Administrator [Thu, 28 Mar 2019 00:01:39 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Wed, 27 Mar 2019 00:01:35 +0000 (00:01 +0000)]
Automatic date update in version.in
Joel Brobecker [Tue, 26 Mar 2019 23:02:09 +0000 (16:02 -0700)]
Bump GDB version number to 8.2.91.DATE-git.
gdb/ChangeLog:
* version.in: Set GDB version number to 8.2.91.DATE-git.
Joel Brobecker [Tue, 26 Mar 2019 23:01:55 +0000 (16:01 -0700)]
Document the GDB 8.2.91 release in gdb/ChangeLog
gdb/ChangeLog:
GDB 8.2.91 released.
Joel Brobecker [Tue, 26 Mar 2019 22:52:05 +0000 (15:52 -0700)]
Set GDB version number to 8.2.91.
gdb/ChangeLog:
* version.in: Set GDB version number to 8.2.91.
Andrew Burgess [Tue, 26 Mar 2019 22:42:01 +0000 (15:42 -0700)]
gdb/testsuite: Prepare for DejaGnu 1.6.2
Changes in DejaGnu 1.6.2 mean that our testsuite will no longer run.
This is because of some confusion over how the gdb.exp file is
handled.
The gdb.exp file is really the tool init file, which is loaded from
within the DejaGnu core, and it should not be loaded directly from any
other file in the testsuite.
DejaGnu tries to prevent the same library being loaded twice by
remembering the names of library files as they are loaded. Until
recently loading the tool init file in DejaGnu was very similar to
loading a library file, as a result, loading the gdb.exp tool init
file simply recorded 'gdb.exp' as having been loaded, future attempts
to load 'gdb.exp' as a library would then be ignored (as the file was
marked as already loaded).
DejaGnu has now changed so that it supports having both a tool init
file and a library with the same name, something that was not possible
before. What this means however is that when the core loads the
'gdb.exp' tool init file it no longer marks the library 'gdb.exp' as
having been loaded. When we then execute 'load_lib gdb.exp' we then
try to reload the 'gdb.exp' file.
Unfortunately our gdb.exp file can only be loaded once. It use of
'rename cd builtin_cd' means that a second attempt to load this file
will fail.
This was discussed on the DejaGnu list here:
http://lists.gnu.org/archive/html/dejagnu/2019-03/msg00000.html
and the suggested advice is that, unless we have some real requirement
to load the tool init file twice, we should remove calls to 'load_lib
gdb.exp' and rely on DejaGnu to load the file for us, which is what
this patch does.
I've tested with native X86-64/GNU Linux and see no regressions.
gdb/testsuite/ChangeLog:
* config/default.exp: Remove 'load_lib gdb.exp'.
* config/monitor.exp: Likewise.
* config/sid.exp: Likewise.
* config/sim.exp: Likewise.
* config/slite.exp: Likewise.
* config/unix.exp: Likewise.
* gdb.base/default.exp: Remove unhelpful comment.
Tom Tromey [Wed, 20 Mar 2019 13:57:09 +0000 (07:57 -0600)]
Merge handle_inferior_event and handle_inferior_event_1
I noticed that handle_inferior_event is just a small wrapper that
frees the value chain. This patch replaces it with a
scoped_value_mark, reducing the number of lines of code here.
Regression tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-03-20 Tom Tromey <tromey@adacore.com>
PR gdb/24391
* infrun.c (handle_inferior_event): Rename from
handle_inferior_event_1. Create a scoped_value_mark.
(handle_inferior_event): Remove.
Simon Marchi [Tue, 26 Mar 2019 00:29:18 +0000 (20:29 -0400)]
Fix use-after-free in source_cache::get_source_lines
Commit
ab42892fb7d2 ("Fix vertical scrolling of TUI source window")
introduced a use-after-free in source_cache::get_source_lines.
At the beginning of the method, we get the fullname of the symtab:
const char *fullname = symtab_to_fullname (s);
fullname points to the string owned by the symtab (s.fullname). When we
later do
scoped_fd desc = open_source_file (s);
s.fullname gets reallocated (even though the string contents may not
change). The fullname local variable now points to freed memory.
To avoid it, refresh the value of fullname after calling
open_source_file.
Here is the ASan report:
$ ./gdb -nx --data-directory=data-directory ./a.out
(gdb) start
Temporary breakpoint 1 at 0x1130: file test.cpp, line 12.
Starting program: /home/simark/build/binutils-gdb/gdb/a.out
Temporary breakpoint 1, main () at test.cpp:12
=================================================================
==26068==ERROR: AddressSanitizer: heap-use-after-free on address 0x6210003d4100 at pc 0x7fed89a34681 bp 0x7ffd8d185d80 sp 0x7ffd8d185528
READ of size 2 at 0x6210003d4100 thread T0
#0 0x7fed89a34680 in __interceptor_strlen /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:301
#1 0x55b6edf6c2f7 in std::char_traits<char>::length(char const*) /usr/include/c++/8.2.1/bits/char_traits.h:320
#2 0x55b6edf6c9b2 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) /usr/include/c++/8.2.1/bits/basic_string.h:516
#3 0x55b6ef09121b in source_cache::get_source_lines(symtab*, int, int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) /home/simark/src/binutils-gdb/gdb/source-cache.c:214
#4 0x55b6ef0a15cb in print_source_lines_base /home/simark/src/binutils-gdb/gdb/source.c:1340
#5 0x55b6ef0a2045 in print_source_lines(symtab*, int, int, enum_flags<print_source_lines_flag>) /home/simark/src/binutils-gdb/gdb/source.c:1415
#6 0x55b6ef112c87 in print_frame_info(frame_info*, int, print_what, int, int) /home/simark/src/binutils-gdb/gdb/stack.c:914
#7 0x55b6ef10e90d in print_stack_frame(frame_info*, int, print_what, int) /home/simark/src/binutils-gdb/gdb/stack.c:180
#8 0x55b6ee9592f8 in print_stop_location /home/simark/src/binutils-gdb/gdb/infrun.c:7853
#9 0x55b6ee95948f in print_stop_event(ui_out*) /home/simark/src/binutils-gdb/gdb/infrun.c:7870
#10 0x55b6ef34b962 in tui_on_normal_stop /home/simark/src/binutils-gdb/gdb/tui/tui-interp.c:98
#11 0x55b6ee01a14d in std::_Function_handler<void (bpstats*, int), void (*)(bpstats*, int)>::_M_invoke(std::_Any_data const&, bpstats*&&, int&&) /usr/include/c++/8.2.1/bits/std_function.h:297
#12 0x55b6ee965415 in std::function<void (bpstats*, int)>::operator()(bpstats*, int) const /usr/include/c++/8.2.1/bits/std_function.h:687
#13 0x55b6ee962f1b in gdb::observers::observable<bpstats*, int>::notify(bpstats*, int) const /home/simark/src/binutils-gdb/gdb/common/observable.h:106
#14 0x55b6ee95a6e7 in normal_stop() /home/simark/src/binutils-gdb/gdb/infrun.c:8142
#15 0x55b6ee93f236 in fetch_inferior_event(void*) /home/simark/src/binutils-gdb/gdb/infrun.c:3782
#16 0x55b6ee8f2641 in inferior_event_handler(inferior_event_type, void*) /home/simark/src/binutils-gdb/gdb/inf-loop.c:43
#17 0x55b6eea2a1f0 in handle_target_event /home/simark/src/binutils-gdb/gdb/linux-nat.c:4358
#18 0x55b6ee7045f1 in handle_file_event /home/simark/src/binutils-gdb/gdb/event-loop.c:733
#19 0x55b6ee704e89 in gdb_wait_for_event /home/simark/src/binutils-gdb/gdb/event-loop.c:859
#20 0x55b6ee7027b5 in gdb_do_one_event() /home/simark/src/binutils-gdb/gdb/event-loop.c:322
#21 0x55b6ee702907 in start_event_loop() /home/simark/src/binutils-gdb/gdb/event-loop.c:371
#22 0x55b6eeadfc16 in captured_command_loop /home/simark/src/binutils-gdb/gdb/main.c:331
#23 0x55b6eeae2ef9 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1174
#24 0x55b6eeae30c2 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1190
#25 0x55b6edf4fa89 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
#26 0x7fed88ad8222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)
#27 0x55b6edf4f86d in _start (/home/simark/build/binutils-gdb/gdb/gdb+0x197186d)
0x6210003d4100 is located 0 bytes inside of 4096-byte region [0x6210003d4100,0x6210003d5100)
freed by thread T0 here:
#0 0x7fed89a8ac19 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:66
#1 0x55b6edfe12df in xfree<char> /home/simark/src/binutils-gdb/gdb/common/common-utils.h:60
#2 0x55b6edfea675 in gdb::xfree_deleter<char>::operator()(char*) const /home/simark/src/binutils-gdb/gdb/common/gdb_unique_ptr.h:34
#3 0x55b6edfe532c in std::unique_ptr<char, gdb::xfree_deleter<char> >::reset(char*) /usr/include/c++/8.2.1/bits/unique_ptr.h:382
#4 0x55b6edfe7329 in std::unique_ptr<char, gdb::xfree_deleter<char> >::operator=(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /usr/include/c++/8.2.1/bits/unique_ptr.h:289
#5 0x55b6ef09ec2b in find_and_open_source(char const*, char const*, std::unique_ptr<char, gdb::xfree_deleter<char> >*) /home/simark/src/binutils-gdb/gdb/source.c:990
#6 0x55b6ef09f56a in open_source_file(symtab*) /home/simark/src/binutils-gdb/gdb/source.c:1069
#7 0x55b6ef090f78 in source_cache::get_source_lines(symtab*, int, int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) /home/simark/src/binutils-gdb/gdb/source-cache.c:205
#8 0x55b6ef0a15cb in print_source_lines_base /home/simark/src/binutils-gdb/gdb/source.c:1340
#9 0x55b6ef0a2045 in print_source_lines(symtab*, int, int, enum_flags<print_source_lines_flag>) /home/simark/src/binutils-gdb/gdb/source.c:1415
#10 0x55b6ef112c87 in print_frame_info(frame_info*, int, print_what, int, int) /home/simark/src/binutils-gdb/gdb/stack.c:914
#11 0x55b6ef10e90d in print_stack_frame(frame_info*, int, print_what, int) /home/simark/src/binutils-gdb/gdb/stack.c:180
#12 0x55b6ee9592f8 in print_stop_location /home/simark/src/binutils-gdb/gdb/infrun.c:7853
#13 0x55b6ee95948f in print_stop_event(ui_out*) /home/simark/src/binutils-gdb/gdb/infrun.c:7870
#14 0x55b6ef34b962 in tui_on_normal_stop /home/simark/src/binutils-gdb/gdb/tui/tui-interp.c:98
#15 0x55b6ee01a14d in std::_Function_handler<void (bpstats*, int), void (*)(bpstats*, int)>::_M_invoke(std::_Any_data const&, bpstats*&&, int&&) /usr/include/c++/8.2.1/bits/std_function.h:297
#16 0x55b6ee965415 in std::function<void (bpstats*, int)>::operator()(bpstats*, int) const /usr/include/c++/8.2.1/bits/std_function.h:687
#17 0x55b6ee962f1b in gdb::observers::observable<bpstats*, int>::notify(bpstats*, int) const /home/simark/src/binutils-gdb/gdb/common/observable.h:106
#18 0x55b6ee95a6e7 in normal_stop() /home/simark/src/binutils-gdb/gdb/infrun.c:8142
#19 0x55b6ee93f236 in fetch_inferior_event(void*) /home/simark/src/binutils-gdb/gdb/infrun.c:3782
#20 0x55b6ee8f2641 in inferior_event_handler(inferior_event_type, void*) /home/simark/src/binutils-gdb/gdb/inf-loop.c:43
#21 0x55b6eea2a1f0 in handle_target_event /home/simark/src/binutils-gdb/gdb/linux-nat.c:4358
#22 0x55b6ee7045f1 in handle_file_event /home/simark/src/binutils-gdb/gdb/event-loop.c:733
#23 0x55b6ee704e89 in gdb_wait_for_event /home/simark/src/binutils-gdb/gdb/event-loop.c:859
#24 0x55b6ee7027b5 in gdb_do_one_event() /home/simark/src/binutils-gdb/gdb/event-loop.c:322
#25 0x55b6ee702907 in start_event_loop() /home/simark/src/binutils-gdb/gdb/event-loop.c:371
#26 0x55b6eeadfc16 in captured_command_loop /home/simark/src/binutils-gdb/gdb/main.c:331
#27 0x55b6eeae2ef9 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1174
#28 0x55b6eeae30c2 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1190
#29 0x55b6edf4fa89 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
previously allocated by thread T0 here:
#0 0x7fed89a8b019 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:86
#1 0x7fed88af983f in realpath@@GLIBC_2.3 (/usr/lib/libc.so.6+0x4583f)
#2 0x7fed899dbbbc in __interceptor_canonicalize_file_name /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:3297
#3 0x55b6ee376a03 in gdb_realpath(char const*) /home/simark/src/binutils-gdb/gdb/common/pathstuff.c:72
#4 0x55b6ef09ec12 in find_and_open_source(char const*, char const*, std::unique_ptr<char, gdb::xfree_deleter<char> >*) /home/simark/src/binutils-gdb/gdb/source.c:990
#5 0x55b6ef09f56a in open_source_file(symtab*) /home/simark/src/binutils-gdb/gdb/source.c:1069
#6 0x55b6ef0a0f12 in print_source_lines_base /home/simark/src/binutils-gdb/gdb/source.c:1270
#7 0x55b6ef0a2045 in print_source_lines(symtab*, int, int, enum_flags<print_source_lines_flag>) /home/simark/src/binutils-gdb/gdb/source.c:1415
#8 0x55b6ef112c87 in print_frame_info(frame_info*, int, print_what, int, int) /home/simark/src/binutils-gdb/gdb/stack.c:914
#9 0x55b6ef10e90d in print_stack_frame(frame_info*, int, print_what, int) /home/simark/src/binutils-gdb/gdb/stack.c:180
#10 0x55b6ee9592f8 in print_stop_location /home/simark/src/binutils-gdb/gdb/infrun.c:7853
#11 0x55b6ee95948f in print_stop_event(ui_out*) /home/simark/src/binutils-gdb/gdb/infrun.c:7870
#12 0x55b6ef34b962 in tui_on_normal_stop /home/simark/src/binutils-gdb/gdb/tui/tui-interp.c:98
#13 0x55b6ee01a14d in std::_Function_handler<void (bpstats*, int), void (*)(bpstats*, int)>::_M_invoke(std::_Any_data const&, bpstats*&&, int&&) /usr/include/c++/8.2.1/bits/std_function.h:297
#14 0x55b6ee965415 in std::function<void (bpstats*, int)>::operator()(bpstats*, int) const /usr/include/c++/8.2.1/bits/std_function.h:687
#15 0x55b6ee962f1b in gdb::observers::observable<bpstats*, int>::notify(bpstats*, int) const /home/simark/src/binutils-gdb/gdb/common/observable.h:106
#16 0x55b6ee95a6e7 in normal_stop() /home/simark/src/binutils-gdb/gdb/infrun.c:8142
#17 0x55b6ee93f236 in fetch_inferior_event(void*) /home/simark/src/binutils-gdb/gdb/infrun.c:3782
#18 0x55b6ee8f2641 in inferior_event_handler(inferior_event_type, void*) /home/simark/src/binutils-gdb/gdb/inf-loop.c:43
#19 0x55b6eea2a1f0 in handle_target_event /home/simark/src/binutils-gdb/gdb/linux-nat.c:4358
#20 0x55b6ee7045f1 in handle_file_event /home/simark/src/binutils-gdb/gdb/event-loop.c:733
#21 0x55b6ee704e89 in gdb_wait_for_event /home/simark/src/binutils-gdb/gdb/event-loop.c:859
#22 0x55b6ee7027b5 in gdb_do_one_event() /home/simark/src/binutils-gdb/gdb/event-loop.c:322
#23 0x55b6ee702907 in start_event_loop() /home/simark/src/binutils-gdb/gdb/event-loop.c:371
#24 0x55b6eeadfc16 in captured_command_loop /home/simark/src/binutils-gdb/gdb/main.c:331
#25 0x55b6eeae2ef9 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1174
#26 0x55b6eeae30c2 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1190
#27 0x55b6edf4fa89 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
#28 0x7fed88ad8222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)
gdb/ChangeLog:
* source-cache.c (source_cache::get_source_lines): Re-read
fullname after calling open_source_file.
GDB Administrator [Tue, 26 Mar 2019 00:01:35 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Mon, 25 Mar 2019 00:01:26 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Sun, 24 Mar 2019 00:01:58 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Sat, 23 Mar 2019 00:01:28 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Fri, 22 Mar 2019 00:01:09 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Thu, 21 Mar 2019 00:00:49 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Wed, 20 Mar 2019 00:00:52 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Tue, 19 Mar 2019 00:00:50 +0000 (00:00 +0000)]
Automatic date update in version.in
Pedro Alves [Mon, 18 Mar 2019 18:58:20 +0000 (18:58 +0000)]
Fix first time you type UP or DOWN in TUI's command window
The first time you type UP or DOWN arrow in the command window, GDB
should scroll the source window, but instead it displays the line
number and the file name in the command window(?).
What happens there is that the first time we call
tui_ui_out::do_field_int, it doesn't initialize m_line, because
m_start_of_line is -1, as set by the constructor; and then the
following call to tui_ui_out::do_field_string falls back to
cli_ui_out::do_field_string because m_line is zero.
The problem is caused by a typo in the C++ification of tui_ui_out,
commit
112e8700a6f, where m_line and m_start_of_line's initial values
were swapped from what they used to be:
-struct ui_out *
-tui_out_new (struct ui_file *stream)
+tui_ui_out::tui_ui_out (ui_file *stream)
+: cli_ui_out (stream, 0),
+ m_line (0),
+ m_start_of_line (-1)
{
-
- /* Initialize our fields. */
- data->line = -1;
- data->start_of_line = 0;
This commit fixes it.
gdb/ChangeLog:
2019-03-18 Pedro Alves <palves@redhat.com>
Eli Zaretskii <eliz@gnu.org>
* tui/tui-out.c (tui_ui_out::tui_ui_out): Fix initialization of
m_line and m_start_of_line.
Eli Zaretskii [Mon, 18 Mar 2019 18:04:40 +0000 (20:04 +0200)]
Fix gdb/TUI behavior in response to [Enter] keypress
gdb/ChangeLog:
2019-03-18 Eli Zaretskii <eliz@gnu.org>
* tui/tui-io.c (gdb_wgetch): Don't echo CR.
(tui_getc): When gdb_wgetch returns a CR, behave the same as when
it returns a newline. This fixes a regression in TUI mode, whereby
the next line is output on the same screen line as the user input.
(cherry picked from commit
b17c4cd078e2d1d8951951016815e474fb133780)
Pedro Alves [Mon, 18 Mar 2019 14:29:44 +0000 (14:29 +0000)]
Improve/fix the TUI's current source line highlight
With styling enabled, I think the way we display the TUI's
highlighted/current line is very ugly and distracting. The problem in
my view is that we reverse foreground/background in colored text as
well, leading to rainbow of background colors.
This patch changes that to something that I find much more sensible --
only reverse the default foreground/background colors, leave styled
text colors alone. If the foreground color is not the default
(because the text was styled), leave the foreground color as is. If
e.g., the terminal is fg=BLACK, and bg=WHITE, and the style wants to
print text in RED, reverse the background color (print in BLACK), but
still print the text in RED.
Note: The new ui_file_style::set_fg method isn't called set_foreground
instead, because set_foreground is a macro in /usr/lib/term.h (ncurses).
gdb/ChangeLog:
2019-03-18 Pedro Alves <palves@redhat.com>
* tui/tui-io.c (reverse_mode_p, reverse_save_bg, reverse_save_fg):
New globals.
(apply_style): New, factored out from ...
(apply_ansi_escape): ... this. Handle reverse video mode.
(tui_set_reverse_mode): New function.
* tui/tui-io.h (tui_set_reverse_mode): New declaration.
* tui/tui-winsource.c (tui_show_source_line): Use
tui_set_reverse_mode instead of setting A_STANDOUT.
* ui-style.h (struct ui_file_style) <set_reverse, set_fg, set_bg>:
New setter methods.
Hannes Domani [Mon, 18 Mar 2019 14:29:43 +0000 (14:29 +0000)]
Fix scrolling right in the TUI
This commit fixes two issues in scrolling right in the TUI:
#1 - Scrolling right with the arrow keys, the first keypress doesn't
do anything. The problem is that copy_source_line() checks if
(column < first_col), and because of the ++column directly before, it
basically starts with 1 instead of 0.
#2 - Scrolling right handles TABS and escaped characters as single
characters, which just looks weird. The problem is that there's a
spot that misses handling TABS.
gdb/ChangeLog:
2019-03-18 Hannes Domani <ssbssa@yahoo.de>
* tui/tui-source.c (copy_source_line): Fix handling of 'column'.
Handle tabs.
GDB Administrator [Mon, 18 Mar 2019 00:01:37 +0000 (00:01 +0000)]
Automatic date update in version.in
Eli Zaretskii [Sun, 17 Mar 2019 16:00:34 +0000 (18:00 +0200)]
Fix redisplay of the current line in GDB TUI mode
Without this change, when the current line is longer than the source
window width, redisplaying that line overwrites the window frame and
also portions of the next line.
gdb/ChangeLog:
2019-03-17 Eli Zaretskii <eliz@gnu.org>
* tui/tui-winsource.c (tui_set_is_exec_point_at): Call
tui_refill_source_window instead of tui_refresh_win, to update the
current execution line. This fixes redisplay of the current line
when stepping through very long lines with "next" or "step".
(cherry picked from commit
f7f0a12390fc514a5b7b38d1b23397d87532ce05)
GDB Administrator [Sun, 17 Mar 2019 00:01:40 +0000 (00:01 +0000)]
Automatic date update in version.in
Eli Zaretskii [Sat, 16 Mar 2019 17:53:46 +0000 (19:53 +0200)]
Fix vertical scrolling of TUI source window
gdb/ChangeLog:
2019-03-16 Eli Zaretskii <eliz@gnu.org>
* source-cache.c (source_cache::get_source_lines): Call
find_source_lines to initialize s->nlines. This fixes vertical
scrolling of TUI source window when the DOWN arrow is pressed.
(cherry picked from commit
ab42892fb7d265e72a85e918d4f5c6dfeee3fcd8)
Eli Zaretskii [Sat, 16 Mar 2019 12:13:43 +0000 (14:13 +0200)]
Revert "Use wclrtoeol in tui_show_source_line"
gdb/ChangeLog:
2019-03-16 Eli Zaretskii <eliz@gnu.org>
* tui/tui-winsource.c (tui_show_source_line): Revert "Use
wclrtoeol in tui_show_source_line". This reverts changes made in
commit
4a3045920bbe4e50a0f4920b0fdc4e88ef23015c.
(cherry picked from commit
798e1c302af509c31839c5c3b50c058b61206ee7)
GDB Administrator [Sat, 16 Mar 2019 00:01:22 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Fri, 15 Mar 2019 00:00:57 +0000 (00:00 +0000)]
Automatic date update in version.in
John Baldwin [Tue, 12 Mar 2019 20:56:53 +0000 (13:56 -0700)]
The NEWS file had two "New targets" sections for 8.3.
gdb/ChangeLog:
* NEWS: Combine separate "New targets" sections for 8.3.
Eli Zaretskii [Thu, 14 Mar 2019 15:31:38 +0000 (17:31 +0200)]
Fix colors in TUI mode in MS-Windows build with ncurses
The MS-Windows port of ncurses fails to switch to a color pair if
one or both of the colors are the implicit default colors. This
change records the default colors when TUI is initialized, and
then specifies them explicitly when a color pair uses the default
colors. This allows color styling in TUI mode on MS-Windows.
gdb/ChangeLog:
2019-03-14 Eli Zaretskii <eliz@gnu.org>
* tui/tui-io.c [__MINGW32__]: Include windows.h. Declare
ncurses_norm_attr.
(tui_initialize_io) [__MINGW32__]: Record the default terminal
colors in ncurses_norm_attr.
(apply_ansi_escape) [__MINGW32__]: If a color in a color pair is
"none", replace it with the default color recorded in
ncurses_norm_attr.
(cherry picked from commit
3fff2c370cd658877be8107bfe9dde8dd0470b46)
Tom Tromey [Fri, 8 Mar 2019 20:59:27 +0000 (13:59 -0700)]
Avoid a crash in source_cache::extract_lines
If the first requested line is larger than the number of lines in the
source buffer, source_cache::extract_lines could crash, because it
would try to pass string::npos" to string::substr.
This patch avoids the crash by checking for this case.
This version of the patch changes get_source_lines to return
std::string.
2019-03-14 Tom Tromey <tromey@adacore.com>
* source-cache.h (class source_cache) <get_source_lines>: Return
std::string.
* source-cache.c (source_cache::extract_lines): Handle case where
first_pos==npos. Return std::string.
(source_cache::get_source_lines): Update.
Tom Tromey [Fri, 8 Mar 2019 20:54:07 +0000 (13:54 -0700)]
Add the "set style source" command
This adds "set style source" (and "show style source") commands. This
gives the user control over whether source code is highlighted.
2019-03-14 Tom Tromey <tromey@adacore.com>
* NEWS: Add item for "style sources" commands.
* source-cache.c (source_cache::get_source_lines): Check
source_styling.
* cli/cli-style.c (source_styling): New global.
(_initialize_cli_style): Add "style sources" commands.
(show_style_sources): New function.
* cli/cli-style.h (source_styling): Declare.
gdb/doc/ChangeLog
2019-03-14 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Output Styling): Document "set style source" and
"show style source".
gdb/testsuite/ChangeLog
2019-03-14 Tom Tromey <tromey@adacore.com>
* gdb.base/style.exp: Add "set style sources" test.
Tom Tromey [Fri, 8 Mar 2019 20:41:55 +0000 (13:41 -0700)]
Make TUI react to "set style enabled"
When the user toggles "set style enabled", the TUI should react by
redrawing the source window, if necessary. This patch implements this
behavior.
No test because the TUI is generally not tested.
This version of the patch incorporates Pedro's patch to provide a
clean way to force the TUI to update the source window's contents.
2019-03-14 Pedro Alves <palves@redhat.com>
Tom Tromey <tromey@adacore.com>
* tui/tui-winsource.h (tui_refill_source_window): Declare.
* tui/tui-winsource.c (tui_refill_source_window): New function,
from...
(tui_horizontal_source_scroll): ... here. Move some logic.
* cli/cli-style.c (set_style_enabled): Notify new observable.
* tui/tui-hooks.c (tui_redisplay_source): New function.
(tui_attach_detach_observers): Attach or detach
tui_redisplay_source.
* observable.h (source_styling_changed): New observable.
* observable.c: Define source_styling_changed observable.
GDB Administrator [Thu, 14 Mar 2019 00:01:00 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Wed, 13 Mar 2019 00:00:39 +0000 (00:00 +0000)]
Automatic date update in version.in
Eli Zaretskii [Tue, 12 Mar 2019 17:47:23 +0000 (19:47 +0200)]
Fix MinGW build with source-highlight
gdb/ChangeLog
2019-03-12 Eli Zaretskii <eliz@gnu.org>
PR/24325
* source-cache.c: #undef open and close, to avoid unresolved
externals during linking.
(cherry picked from commit
3a3508220eecf27e1952a73cd3ea6d6314ce8e1d)
GDB Administrator [Tue, 12 Mar 2019 00:00:53 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Mon, 11 Mar 2019 00:00:46 +0000 (00:00 +0000)]
Automatic date update in version.in
GDB Administrator [Sun, 10 Mar 2019 00:01:33 +0000 (00:01 +0000)]
Automatic date update in version.in
Eli Zaretskii [Sat, 9 Mar 2019 06:44:56 +0000 (08:44 +0200)]
Support styling on native MS-Windows console
gdb/ChangeLog:
2019-03-08 Eli Zaretskii <eliz@gnu.org>
PR/24315
* utils.c (can_emit_style_escape) [_WIN32]: Don't disable styling
on MS-Windows if $TERM is not defined.
* cli/cli-style.c: Set cli_styling to 1 in the MinGW build.
* posix-hdep.c (gdb_console_fputs):
* mingw-hdep.c (rgb_to_16colors, gdb_console_fputs): New
functions.
* ui-file.h (gdb_console_fputs): Add prototype.
* ui-file.c (stdio_file::puts): Call gdb_console_fputs, and fall
back to fputs only if the former returns zero.
(cherry picked from commit
e4adb93903d4ae0b7ab2b5004364e50627df95f7)
GDB Administrator [Sat, 9 Mar 2019 00:01:21 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Fri, 8 Mar 2019 00:01:48 +0000 (00:01 +0000)]
Automatic date update in version.in
Rainer Orth [Thu, 7 Mar 2019 21:00:05 +0000 (22:00 +0100)]
Can't interrupt process without controlling terminal on Solaris (PR gdb/8527)
If gdb attaches to a process that either has no controlling terminal,
or the controlling terminal differs from the one gdb is running under,
break/^C doesn't interrupt the debugged process on Solaris.
Fixed as follows, analogous to what all all other targets do. Patch from
the PR, recently re-submitted by Brian Vandenberg.
Tested on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11, and
x86_64-pc-linux-gnu.
2019-03-07 Brian Vandenberg <phantall@gmail.com>
Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gdb:
PR gdb/8527
* procfs.c (proc_wait_for_stop): Wrap write of PCWSTOP in
set_sigint_trap, clear_sigint_trap.
gdb/testsuite:
PR gdb/8527
* gdb.base/interrupt-daemon-attach.c,
gdb.base/interrupt-daemon-attach.exp: New test.
GDB Administrator [Thu, 7 Mar 2019 00:01:40 +0000 (00:01 +0000)]
Automatic date update in version.in
Alan Hayward [Wed, 6 Mar 2019 09:52:08 +0000 (09:52 +0000)]
Testsuite: Ensure changing directory does not break the log file
get_compiler_info switches to a new log file before checking the compiler
to ensure the checks are not logged. Afterwards it restores back to using
the original log file. However, the logfile uses a relative path name -
if the current test has changed the current directory then all further
output for the test will be lost. This can confuse the code that collates
the main gdb.log file at the end of a FORCE_PARALLEL run.
fullpath-expand.exp calls gdb_compile after changing the current directory.
The "Ensure stack protection is off for GCC" patch added a call to
get_compiler_info from inside of gdb_compile, causing log file collection
to break for FORCE_PARALLEL runs.
The ideal solution would be to ensure the log file is always created using
an absolute path name. However, this is set at multiple points in
Makefile.in and in some instances just relies on dejagnu common code to set
the log file directory to "."
The simpler and safer solution is to override the builtin cd function. The
new function checks the current log file and if the path is relative, then
it resets the logging using an absolute path. Finally it calls the builtin
cd. This ensures get_compiler_info (and any other code) can correctly
backup and restore the current log file.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (builtin_cd): rename of cd.
(cd): Override builtin.
GDB Administrator [Wed, 6 Mar 2019 00:01:21 +0000 (00:01 +0000)]
Automatic date update in version.in
Sergio Durigan Junior [Mon, 4 Mar 2019 17:44:20 +0000 (12:44 -0500)]
Use '$enable_unittest' instead of '$development' on gdbserver/configure.srv (for 'aarch64*-*-linux*' case)
On commit
8ecfd7bd4acd69213c06fac6de9af38299123547 ("Add parameter to
allow enabling/disabling selftests via configure") it seems that I
forgot to use the proper '$enable_unittest' variable when checking to
see whether to add selftest-related objects to 'srv_regobj'. This
causes a build failure on Aarch64 when 'development=false' (which is
the case for the 8.3 branch) and 'enable_unittest=true'.
This patch fixes the problem by using '$enable_unittest' instead of
'$development' when performing the check. As a reminder, it's
important to notice that '$enable_unittest's default value (i.e., when
the option '--enable-unit-tests' is not passed to configure) is the
same as '$development', so this patch doesn't affect the current
build.
I'd like to install this patch both on master and on the 8.3 branch.
OK?
gdb/gdbserver/ChangeLog:
2019-03-04 Sergio Durigan Junior <sergiodj@redhat.com>
* configure.srv: Use '$enable_unittest' instead of '$development'
when checking whether to fill 'srv_regobj' on 'aarch64*-*-linux*'
case.
GDB Administrator [Tue, 5 Mar 2019 00:01:29 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Mon, 4 Mar 2019 00:01:11 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Sun, 3 Mar 2019 00:02:14 +0000 (00:02 +0000)]
Automatic date update in version.in
Eli Zaretskii [Sat, 2 Mar 2019 19:42:54 +0000 (21:42 +0200)]
Fix documentation of styles.
gdb/doc/ChangeLog:
2019-03-02 Eli Zaretskii <eliz@gnu.org>
* gdb.texinfo (Output Styling): Fix typos. Document the default
foreground colors of the available styles.
(cherry picked from commit
e3624a40aeb31065c968d0d3a1d55fdf8e8a4e3c)
Eli Zaretskii [Sat, 2 Mar 2019 13:22:11 +0000 (15:22 +0200)]
Avoid compilation warnings on MinGW.
gdb/ChangeLog:
2019-03-02 Eli Zaretskii <eliz@gnu.org>
* xml-syscall.c (xml_list_syscalls_by_group): Drop 'struct' from
for-loop range, to avoid compiler warnings.
* tui/tui.c (tui_enable) [__MINGW32__]: Don't declare 'cap', to
avoid compiler warnings about unused variables.
(cherry picked from commit
a6a4b2c636b29de09dea890b448f99804ef7bc18)
Eli Zaretskii [Sat, 2 Mar 2019 13:18:32 +0000 (15:18 +0200)]
GDB no longer supports Windows before XP.
gdb/ChangeLog:
2019-03-02 Eli Zaretskii <eliz@gnu.org>
* NEWS: Mention end of support for native debugging on MS-Windows
before XP.
(cherry picked from commit
742a7df5f4a149f0818aaccfc432c4c0c9a6e26d)
Eli Zaretskii [Sat, 2 Mar 2019 13:13:54 +0000 (15:13 +0200)]
Fix GDB compilation on MinGW (PR gdb/24292)
gdb/ChangeLog:
2019-03-02 Eli Zaretskii <eliz@gnu.org>
PR gdb/24292
* common/netstuff.c:
* gdbserver/gdbreplay.c
* gdbserver/remote-utils.c:
* ser-tcp.c:
* unittests/parse-connection-spec-selftests.c [USE_WIN32API]:
Include ws2tcpip.h instead of wsiapi.h and winsock2.h. Redefine
_WIN32_WINNT to 0x0501 if defined to a smaller value, as
'getaddrinfo' and 'freeaddrinfo' were not available before
Windows XP, and mingw.org's MinGW headers by default define
_WIN32_WINNT to 0x500.
(cherry picked from commit
41fa577fbc326402be49b3f03bc828e52dba8b88)
GDB Administrator [Sat, 2 Mar 2019 00:01:40 +0000 (00:01 +0000)]
Automatic date update in version.in
GDB Administrator [Fri, 1 Mar 2019 00:02:06 +0000 (00:02 +0000)]
Automatic date update in version.in
GDB Administrator [Thu, 28 Feb 2019 00:01:49 +0000 (00:01 +0000)]
Automatic date update in version.in
Kevin Buettner [Fri, 22 Feb 2019 00:22:13 +0000 (17:22 -0700)]
Document fact that mininum Python version is now 2.6
gdb/ChangeLog:
* NEWS: Note minimum Python version.
gdb/doc/ChangeLog:
* gdb.texinfo (Configure Options): Document minimum python
version.
Joel Brobecker [Wed, 27 Feb 2019 05:36:33 +0000 (09:36 +0400)]
Bump GDB version number to 8.2.90.DATE-git.
gdb/ChangeLog:
* version.in: Set GDB version number to 8.2.90.DATE-git.
Joel Brobecker [Wed, 27 Feb 2019 05:29:44 +0000 (09:29 +0400)]
Document the GDB 8.2.90 release in gdb/ChangeLog
gdb/ChangeLog:
GDB 8.2.90 released.
Joel Brobecker [Wed, 27 Feb 2019 05:19:57 +0000 (09:19 +0400)]
Set GDB version number to 8.2.90.
gdb/ChangeLog:
* version.in: Set GDB version number to 8.2.90.
Joel Brobecker [Wed, 27 Feb 2019 05:06:55 +0000 (09:06 +0400)]
change section name in gdb/NEWS for changes in GDB 8.3
gdb/ChangeLog:
* NEWS: Change "Changes since GDB 8.2" into "Changes in GDB 8.3".
Joel Brobecker [Wed, 27 Feb 2019 04:53:29 +0000 (08:53 +0400)]
Set development mode to "off" by default.
bfd/ChangeLog:
* development.sh (development): Set to false.
Joel Brobecker [Wed, 27 Feb 2019 04:52:26 +0000 (08:52 +0400)]
Bump version to 8.2.90.DATE-git.
Now that the GDB 8.3 branch has been created, we can
bump the version number.
gdb/ChangeLog:
GDB 8.3 branch created (
143420fb0d5ae54323ba9953f0818c194635228d):
* version.in: Bump version to 8.2.90.DATE-git.
Simon Marchi [Wed, 27 Feb 2019 04:45:50 +0000 (23:45 -0500)]
Fix build errors in aix-thread.c
This patch fixes a few instances of unused variable and shadowed local
variable errors.
gdb/ChangeLog:
* aix-thread.c (ptid_cmp): Remove unused variable.
(get_signaled_thread): Likewise.
(store_regs_user_thread): Likewise.
(store_regs_kernel_thread): Likewise.
(fetch_regs_kernel_thread): Remove shadowed variable.
GDB Administrator [Wed, 27 Feb 2019 00:00:37 +0000 (00:00 +0000)]
Automatic date update in version.in
Andrew Burgess [Sat, 23 Feb 2019 20:07:47 +0000 (22:07 +0200)]
gdb/riscv: Use legacy register numbers in default target description
When the target description support was added to RISC-V, the register
numbers assigned to the fflags, frm, and fcsr control registers in the
default target descriptions didn't match the register numbers used by
GDB before the target description support was added.
What this means is that if a tools exists in the wild that is using
hard-coded register number, setup to match GDB's old numbering, then
this will have been broken (for fflags, frm, and fcsr) by the move to
target descriptions. QEMU is such a tool.
There are a couple of solutions that could be used to work around this
issue:
- The user can create their own xml description file with the
register numbers setup to match their old tool, then load this by
telling GDB 'set tdesc filename FILENAME'.
- Update their old tool to use the newer default numbering scheme, or
better yet add proper target description support to their tool.
- We could have RISC-V GDB change to maintain the old defaults.
This patch changes GDB back to using the old numbering scheme.
This change is only visible to remote targets that don't supply their
own xml description file and instead rely on GDB's default numbering.
Note that even though 32bit-cpu.xml and 64bit-cpu.xml have changed,
the corresponding .c file has not, this is because the numbering added
to the registers in the xml files is number 0, this doesn't result in
any new C code being generated .
gdb/ChangeLog:
* features/riscv/32bit-cpu.xml: Add register numbers.
* features/riscv/32bit-fpu.c: Regenerate.
* features/riscv/32bit-fpu.xml: Add register numbers.
* features/riscv/64bit-cpu.xml: Add register numbers.
* features/riscv/64bit-fpu.c: Regenerate.
* features/riscv/64bit-fpu.xml: Add register numbers.
Tom Tromey [Tue, 26 Feb 2019 19:12:30 +0000 (12:12 -0700)]
Fix new py-value.exp test case
The new test case in py-value.exp fails -- the code was changed to
throw ValueError, but the test still checks for TypeError. This patch
fixes the problem.
I'm checking this in. Tested on x86-64 Fedora 29.
gdb/testsuite/ChangeLog
2019-02-26 Tom Tromey <tromey@adacore.com>
* gdb.python/py-value.exp (test_value_from_buffer): Check for
ValueError, not TypeError.
Kevin Buettner [Sun, 17 Feb 2019 01:31:51 +0000 (18:31 -0700)]
Document two argument form of gdb.Value constructor
gdb/ChangeLog:
* NEWS: Mention two argument form of gdb.Value constructor.
gdb/doc/ChangeLog:
* python.texi (Values From Inferior): Document second form
of Value.__init__.
Kevin Buettner [Sun, 17 Feb 2019 01:07:51 +0000 (18:07 -0700)]
Add tests for gdb.Value(bufobj, type) constructor
gdb/testsuite/ChangeLog:
* gdb.python/py-value.exp (test_value_from_buffer): New proc with
call from main program.
Kevin Buettner [Sun, 17 Feb 2019 00:46:33 +0000 (17:46 -0700)]
Define gdb.Value(bufobj, type) constructor
Provided a buffer BUFOBJ and a type TYPE, construct a gdb.Value object
with type TYPE, where the value's contents are taken from BUFOBJ.
E.g...
(gdb) python import struct
(gdb) python unsigned_int_type=gdb.lookup_type('unsigned int')
(gdb) python b=struct.pack('=I',0xdeadbeef)
(gdb) python v=gdb.Value(b, unsigned_int_type) ; print("%#x" % v)
0xdeadbeef
This two argument form of the gdb.Value constructor may also be used
to obtain gdb values from selected portions of buffers read with
Inferior.read_memory(). The test case (which is in a separate patch)
demonstrates this use case.
gdb/ChangeLog:
* python/py-value.c (convert_buffer_and_type_to_value): New
function.
(valpy_new): Parse arguments via gdb_PyArg_ParseTupleAndKeywords.
Add support for handling an optional second argument. Call
convert_buffer_and_type_to_value as appropriate.
Kevin Buettner [Sun, 17 Feb 2019 00:33:47 +0000 (17:33 -0700)]
Define unique_ptr specialization for Py_buffer.
This patch causes PyBuffer_Release() to be called when the associated
buffer goes out of scope. I've been using it as follows:
...
Py_buffer_up buffer_up;
Py_buffer py_buf;
if (PyObject_CheckBuffer (obj)
&& PyObject_GetBuffer (obj, &py_buf, PyBUF_SIMPLE) == 0)
{
/* Got a buffer, py_buf, out of obj. Cause it to released
when it goes out of scope. */
buffer_up.reset (&py_buf);
}
...
This snippet of code was taken directly from an upcoming patch to
python-value.c.
gdb/ChangeLog:
* python/python-internal.h (Py_buffer_deleter): New struct.
(Py_buffer_up): New typedef.
GDB Administrator [Tue, 26 Feb 2019 00:00:25 +0000 (00:00 +0000)]
Automatic date update in version.in
John Baldwin [Mon, 25 Feb 2019 22:25:01 +0000 (14:25 -0800)]
Fix BFD leak in dwarf2_get_dwz_file.
Previously if build_id_verify failed, dwz_bfd was cleared to NULL via
release(), but the BFD object was not destroyed. Use reset() with
nullptr instead to delete the BFD.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_get_dwz_file): Reset dwz_bfd to nullptr
instead of releasing ownership.
Jordan Rupprecht [Mon, 25 Feb 2019 20:21:01 +0000 (12:21 -0800)]
Fix crash when loading dwp files
When loading dwp files, we create an array of ELF sections indexed by the ELF
section index in the dwp file. The size of this array is calculated by
section_count, as returned by bfd_count_sections, plus 1 (to account for the
null section at index 0). However, when loading the bfd file, strtab/symtab
sections are not added to the list, nor do they increment section_count, so
section_count is actually smaller than the number of ELF sections.
This happens to work when using GNU dwp, which lays out .debug section first,
with sections like .shstrtab coming at the end. Other tools, like llvm-dwp, put
.strtab first, and gdb crashes when loading those dwp files.
For instance, with the current state of gdb, loading a file like this:
$ readelf -SW <file.dwp>
[ 0] <empty>
[ 1] .debug_foo PROGBITS ...
[ 2] .strtab STRTAB ...
... results in section_count = 2 (.debug is the only thing placed into
bfd->sections, so section_count + 1 == 2), and sectp->this_idx = 1 when mapping
over .debug_foo in dwarf2_locate_common_dwp_sections, which passes the
assertion that 1 < 2.
However, using a dwp file produced by llvm-dwp:
$ readelf -SW <file.dwp>
[ 0] <empty>
[ 1] .strtab STRTAB ...
[ 2] .debug_foo PROGBITS ...
... results in section_count = 2 (.debug is the only thing placed into
bfd->sections, so section_count + 1 == 2), and sectp->this_idx = 2 when mapping
over .debug_foo in dwarf2_locate_common_dwp_sections, which fails the assertion
that 2 < 2.
The assertion hit is:
gdb/dwarf2read.c:13009: internal-error: void dwarf2_locate_common_dwp_sections(bfd*, asection*, void*): Assertion `elf_section_nr < dwp_file->num_sections' failed.
This patch changes the calculation of section_count to use elf_numsections,
which should return the actual number of ELF sections.
Tom Tromey [Thu, 21 Feb 2019 17:40:49 +0000 (10:40 -0700)]
Fix BFD leak in solib-darwin.c
commit
192b62ce0b4bb5c61188f570e127a26d2c32f716 ("Use class to manage
BFD reference counts") changed darwin_get_dyld_bfd to use:
+ dyld_bfd.release ();
rather than
- do_cleanups (cleanup);
However, using release here leaks the BFD. Instead, simply assigning
"sub" to "dyld_bfd" achieves what was meant.
gdb/ChangeLog
2019-02-25 Tom Tromey <tromey@adacore.com>
* solib-darwin.c (darwin_get_dyld_bfd): Don't release dyld_bfd.