This patch initialize res to zero, otherwise, it may have some garbage
bits after the *the_target->read_memory call.
gdb/gdbserver:
2016-05-05 Yao Qi <yao.qi@linaro.org>
* linux-arm-low.c (get_next_pcs_read_memory_unsigned_integer):
Initialize res to zero.
Variable cpsr holds the value of cpsr register, which is 32-bit. It
is better to explicitly use uint32_t.
gdb/gdbserver:
2016-05-05 Yao Qi <yao.qi@linaro.org>
* linux-arm-low.c (arm_sigreturn_next_pc): Change type of cpsr
to uint32_t.
ChangeLog:
* spu-linux-nat.c (spu_bfd_iovec_pread): Add pointer cast for C++.
(spu_bfd_open): Likewise.
gdbserver/ChangeLog:
* spu-low.c (fetch_ppc_register): Cast PowerPC-Linux-specific value
used as first ptrace argument to PTRACE_TYPE_ARG1 for C++.
(fetch_ppc_memory_1, store_ppc_memory_1): Likewise.
Nowadays, read_memory may throw NOT_AVAILABLE_ERROR (it is done by
patch http://sourceware.org/ml/gdb-patches/2013-08/msg00625.html)
however, read_stack and read_code still throws MEMORY_ERROR only. This
causes PR 19947, that is prologue unwinder is unable unwind because
code memory isn't available, but MEMORY_ERROR is thrown, while unwinder
catches NOT_AVAILABLE_ERROR.
#0 memory_error (err=err@entry=TARGET_XFER_E_IO, memaddr=memaddr@entry=140737349781158) at /home/yao/SourceCode/gnu/gdb/git/gdb/corefile.c:217
#1 0x000000000065f5ba in read_code (memaddr=memaddr@entry=140737349781158, myaddr=myaddr@entry=0x7fffffffd7b0 "\340\023<\001", len=len@entry=1)
at /home/yao/SourceCode/gnu/gdb/git/gdb/corefile.c:288
#2 0x000000000065f7b5 in read_code_unsigned_integer (memaddr=memaddr@entry=140737349781158, len=len@entry=1, byte_order=byte_order@entry=BFD_ENDIAN_LITTLE)
at /home/yao/SourceCode/gnu/gdb/git/gdb/corefile.c:363
#3 0x00000000004717e0 in amd64_analyze_prologue (gdbarch=gdbarch@entry=0x13c13e0, pc=140737349781158, current_pc=140737349781165, cache=cache@entry=0xda0cb0)
at /home/yao/SourceCode/gnu/gdb/git/gdb/amd64-tdep.c:2267
#4 0x0000000000471f6d in amd64_frame_cache_1 (cache=0xda0cb0, this_frame=0xda0bf0) at /home/yao/SourceCode/gnu/gdb/git/gdb/amd64-tdep.c:2437
#5 amd64_frame_cache (this_frame=0xda0bf0, this_cache=<optimised out>) at /home/yao/SourceCode/gnu/gdb/git/gdb/amd64-tdep.c:2508
#6 0x000000000047214d in amd64_frame_this_id (this_frame=<optimised out>, this_cache=<optimised out>, this_id=0xda0c50)
at /home/yao/SourceCode/gnu/gdb/git/gdb/amd64-tdep.c:2541
#7 0x00000000006b94c4 in compute_frame_id (fi=0xda0bf0) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:481
#8 get_prev_frame_if_no_cycle (this_frame=this_frame@entry=0xda0b20) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:1809
#9 0x00000000006bb6c9 in get_prev_frame_always_1 (this_frame=0xda0b20) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:1983
#10 get_prev_frame_always (this_frame=this_frame@entry=0xda0b20) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:1999
#11 0x00000000006bbe11 in get_prev_frame (this_frame=this_frame@entry=0xda0b20) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:2241
#12 0x00000000006bc13c in unwind_to_current_frame (ui_out=<optimised out>, args=args@entry=0xda0b20) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:1485
The fix is to let read_stack and read_code throw NOT_AVAILABLE_ERROR too,
in order to align with read_memory.
gdb:
2016-05-04 Yao Qi <yao.qi@linaro.org>
PR gdb/19947
* corefile.c (read_memory): Rename it to ...
(read_memory_object): ... it. Add parameter object.
(read_memory): Call read_memory_object.
(read_stack): Likewise.
(read_code): Likewise.
This test currently uses [is_remote target] to check if the test is
supported. This is not quite correct, as the limitation is actually
that it requires support for "running", ruling out stub-like targets.
Therefore, it should check for use_gdb_stub.
This has no visible effect right now, but it will once we make the
native-gdbserver board non-dejagnu-remote.
gdb/testsuite/ChangeLog:
* gdb.base/solib-display.exp: Check for [use_gdb_stub] instead
of [is_remote target],
This patch introduces the use_gdb_stub procedure, which allows getting
the right value of the use_gdb_stub variable/property in any all
situations.
When calling it before the $use_gdb_stub global variable has been set,
it will return the value of the use_gdb_stub property from the board
file. This happens when tests want to bail out early (even before gdb
has been started) when the current test setup is a stub.
Otherwise, it returns the value of the $use_gdb_stub global.
It's possible for these two to differ when a test file overrides the
value of the global.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (use_gdb_stub): New procedure.
PR symtab/19914
* dwarf2read.c (open_and_init_dwp_file): Look at backlink if objfile
is separate debug file.
testsuite/
* gdb.dwarf2/dwp-sepdebug.c: New file.
* gdb.dwarf2/dwp-sepdebug.exp: New file.
Valgrind shows:
==26964== Invalid read of size 1
==26964== at 0x6E14100: __GI_strcmp (strcmp.S:180)
==26964== by 0x6DB55AA: setlocale (setlocale.c:238)
==26964== by 0x4E0455: _initialize_python() (python.c:1731)
==26964== by 0x786731: initialize_all_files() (init.c:319)
==26964== by 0x72EF0A: gdb_init(char*) (top.c:1929)
==26964== by 0x60BCAC: captured_main(void*) (main.c:863)
==26964== by 0x606AD5: catch_errors(int (*)(void*), void*, char*, return_mask) (exceptions.c:234)
==26964== by 0x60C608: gdb_main(captured_main_args*) (main.c:1165)
==26964== by 0x40CAEC: main (gdb.c:32)
==26964== Address 0x81d30a0 is 0 bytes inside a block of size 181 free'd
==26964== at 0x4C29CF0: free (vg_replace_malloc.c:530)
==26964== by 0x6DB5B65: setname (setlocale.c:201)
==26964== by 0x6DB5B65: setlocale (setlocale.c:388)
==26964== by 0x4E037F: _initialize_python() (python.c:1712)
==26964== by 0x786731: initialize_all_files() (init.c:319)
==26964== by 0x72EF0A: gdb_init(char*) (top.c:1929)
==26964== by 0x60BCAC: captured_main(void*) (main.c:863)
==26964== by 0x606AD5: catch_errors(int (*)(void*), void*, char*, return_mask) (exceptions.c:234)
==26964== by 0x60C608: gdb_main(captured_main_args*) (main.c:1165)
==26964== by 0x40CAEC: main (gdb.c:32)
The problem is doing this:
oldloc = setlocale (LC_ALL, NULL);
setlocale (LC_ALL, "");
...
setlocale (LC_ALL, oldloc);
I.e., the second setlocale call frees 'oldloc'.
From http://pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html :
"The returned string pointer might be invalidated or the string
content might be overwritten by a subsequent call to setlocale()."
gdb/ChangeLog:
2016-05-03 Pedro Alves <palves@redhat.com>
PR python/20037
* python/python.c (_initialize_python) [IS_PY3K]: xstrdup/xfree
oldloc.
This makes no sense -- strlen doesn't really ever fail with -1.
gdb/ChangeLog:
2016-05-03 Pedro Alves <palves@redhat.com>
* python/python.c (_initialize_python) [IS_PY3K]: Remove dead
code.
GDB's use of --dynamic-list to only export the proc-service symbols is
broken due to Python's "python-config --ldflags" saying we should link
with -export-dynamic, causing us to export _all_ extern symbols
anyway. On Fedora 23:
$ python-config --ldflags
-lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic
$ python3.4-config --ldflags
-L/usr/lib64 -lpython3.4m -lpthread -ldl -lutil -lm -Xlinker -export-dynamic
Having GDB export all its symbols leads to issues such as PR gdb/16818
(GDB crashes when using name for target remote hostname:port), where a
GDB symbol unintentionally preempts a symbol in one of the NSS modules
glibc loads into the process. NSS modules should not define symbols
outside the implementation namespace or the relevant standards, but,
alas, that's a longstanding and hard to fix issue. See libc-alpha
discussion at:
[symbol name space issues with NSS modules]
https://sourceware.org/ml/libc-alpha/2016-04/msg00130.html
Python should instead be either using GCC's symbol visibility feature
or -Wl,--dynamic-list as well, to only export Python API symbols, but,
it doesn't. There are bugs open upstream for that:
[Use -Wl,--dynamic-list=x.list, not -Xlinker -export-dynamic]
http://bugs.python.org/issue10112
[Use GCC visibility attrs in PyAPI_*]
http://bugs.python.org/issue11410
But that's taking a long while to resolve.
I thought of working around this Python issue by making GDB build with
-fvisibility=hidden, as Jan suggests in Python issue 10112, as then
Python's "-Xlinker -export-dynamic" has no effect. However, that
would need to be done in the whole source tree (bfd, libiberty, etc.),
and I think that would break GCC plugins, as I believe those have
access to all of GCCs symbols, by "design". So we'd need a new
configure switch, or have the libraries in the tree detect which of
GCC or GDB is being built, but that doesn't work, because the answer
can be "both" with combined builds...
So this patch instead works around Python's bug, by simply sed'ing
away "-Xlinker -export-dynamic" from the result of python-config.py
--ldflags, making -Wl,--dynamic-list work again as it used to. It's
ugly, but so is the bug...
Note that if -Wl,--dynamic-list doesn't work, we always link with
-rdynamic, so static Python should still work.
Tested on F23 with --python=python (Python 2.7) and
--python=python3.4.
gdb/ChangeLog:y
2016-05-03 Pedro Alves <palves@redhat.com>
* configure.ac (PYTHON_LIBS): Sed away "-Xlinker -export-dynamic".
* configure: Regenerate.
The -Wl,--dynamic-list test is currently broken on Fedora 23, when you
configure with --with-python=python3.4. We see:
configure:13741: checking for the dynamic export flag
configure:13796: gcc -o conftest -g3 -O0 -fno-strict-aliasing -DNDEBUG -fwrapv -Wl,--dynamic-list=/home/pedro/gdb/mygit/src/gdb/proc-service.list conftest.c -ldl -lncurses -lm -ldl -lpthread -ldl -lutil -lm -lpython3.4m -Xlinker -export-dynamic >&5
conftest.c:182:30: fatal error: python3.4/Python.h: No such file or directory
compilation terminated.
configure:13796: $? = 1
The correct -I path is in PYTHON_CPPFLAGS:
PYTHON_CPPFLAGS='-I/usr/include/python3.4m -I/usr/include/python3.4m'
(Other Python-related tests in the file are already doing this.)
gdb/ChangeLog:
2016-05-03 Pedro Alves <palves@redhat.com>
* configure.ac (checking for the dynamic export flag): Add
$PYTHON_CPPFLAGS to CPPFLAGS.
* configure: Regenerate.
This test seems to work with both native-gdbserver and
native-extended-gdbserver, so I removed the remote check.
When running with native-gdbserver (a stub-like target), detach makes
gdbserver stop and gdb disconnect. runto_main just spawns a brand new
gdbserver. So it tests the exact same thing twice. It doesn't hurt
though.
With native-extended-gdbserver, the test is probably a bit more useful
(and similar to native). It tests running/detaching twice using the
same gdb/gdbserver instances, since with extended-remote, you can
detach/attach/run all you want, unlike with remote.
gdb/testsuite/ChangeLog:
* gdb.base/detach.exp: Remove is_remote check.
The comment says that we can't use runto_main here becore it doesn't
know how to handle annotation. Instead, the test puts a breakpoint at
main and calls run by hand. Therefore, it can't work with stub targets,
since they can't "run". The check should be then changed to check the
use_gdb_stub variable instead of [is_remote target].
But as an alternative, we can just use runto_main and enable annotations
after, since the "run to main" part is not really part of what we want
to test.
I also removed the "set test..." line that is unused.
gdb/testsuite/ChangeLog:
* gdb.base/annota-input-while-running.exp: Don't check for
[is_remote target]. Enable annotations after running to main.
Remove unused "set test..." line.
* windows-nat.c (_initialize_check_for_gdb_ini): Fix off-by-one
error in allocation of space for "$HOME/.gdbinit" string. This
caused GDB to abort on startup whenever a '~/gdb.ini' file was
actually found, because xsnprintf would hit an assertion
violation.
Just like completion doesn't show deprecated commands, I think that help
should not list them, so that we don't incite users to use them.
gdb/ChangeLog:
* cli/cli-decode.c (help_cmd_list): Do not list commands that
are deprecated.
This patch adds a test for tracepoints enabling/disabling, which
didn't work properly for fast tracepoints on big endian systems.
gdb/testsuite/ChangeLog:
* gdb.trace/trace-enable-disable.exp: New file.
* gdb.trace/trace-enable-disable.c: New file.
I am sending this fix on behalf of Par Olsson, as a follow-up of this
one:
https://www.sourceware.org/ml/gdb-patches/2015-10/msg00196.html
This problem is exposed when enabling/disabling fast tracepoints on big
endian machines. The flag is defined as an int8_t, but is written from
gdbserver as an integer (usually 32 bits). When the agent code reads it
as an int8_t, it only considers the most significant byte, which is
always 0.
Also, we were writing 32 bits in an 8 bits field, so the write would
overflow, but since the following bytes are padding (the next field is
an uint64_t), it luckily didn't cause any issue on little endian
systems.
The fix was originally tested on ARM big endian systems, but I don't
have access to such a system. However, thanks to Marcin's PowerPC fast
tracepoint patches and gcc110 (big endian Power7) on the gcc compile
farm, I was able to reproduce the problem, test the fix and write a
test (the following patch).
gdb/gdbserver/ChangeLog:
YYYY-MM-DD Par Olsson <par.olsson@windriver.com>
* tracepoint.c (write_inferior_int8): New function.
(cmd_qtenable_disable): Write enable flag using
write_inferior_int8.
Some fast tracepoints tests make sure that the in-process agent library
is properly loaded, by searching for the library name in "info
sharedlibrary".
Originally, it would search for the full path. Since patch "Make ftrace
tests work with remote targets" [1], the "runtime" location of the IPA,
in the standard output directory, is not the same as the original
location, in the gdbserver build directory. Therefore, the patch
changed the checks:
gdb_test "info sharedlibrary" ".*${libipa}.*" "IPA loaded"
to
gdb_test "info sharedlibrary" ".*[file tail ${libipa}].*" "IPA loaded"
so that only the "libinproctrace.so" part would be searched for.
Antoine (in CC) pointed out that I missed some, so I have to update
them. In the mean time, I noticed that I missed a few test failures:
adding the SONAME to the IPA makes it possible for the test executable
to erroneously pick up libinproctrace.so from /usr/lib if the test
harness failed to put the libinproctrace.so we want to test in the right
place. To mitigate that kind of error in the future, we can use the
return value of gdb_load_shlib (the path of the "runtime" version of the
library) and use that to search in the output of info sharedlibrary.
When testing locally, gdb_load_shlib returns the full normalized path of
the destination library, which the test executable should use e.g.:
/path/to/gdb/testsuite/outputs/gdb.trace/thetest/libinproctrace.so
My testing showed that it was the same path that gdb displayed in info
sharedlibrary. If the test executable picks up another
libinproctrace.so, the test will fail.
When testing remotely, gdb_load_shlib/gdb_remote_download only returns
us "libinproctrace.so", so the situation doesn't really change. If
there is a rogue libinproctrace.so in /usr/lib on the target and we fail
to download ours, it might cover up a test failure. But that situation
is probably still better than the original one, where it wasn't possible
to test remotely using the IPA at all.
[1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=6e774b13c3b81ac2599812adf058796948ce7e95
gdb/testsuite/ChangeLog:
* gdb.arch/ftrace-insn-reloc.exp: Save gdb_load_shlib result,
use it in info sharedlibrary test.
* gdb.trace/ftrace-lock.exp: Likewise.
* gdb.trace/ftrace.exp: Likewise.
* gdb.trace/range-stepping.exp: Likewise.
* gdb.trace/trace-break.exp: Likewise.
* gdb.trace/trace-condition.exp: Likewise.
* gdb.trace/trace-mt.exp: Likewise.
Hi,
I happen to see that field need_step_over in struct lwp_info is only
used to print a debug info. need_step_over is set in linux_wait_1
when breakpoint_here is true, however, we check breakpoint_here too in
need_step_over_p and do the step over. I think we don't need field
need_step_over, and check breakpoint_here directly in need_step_over_p.
This field was added in this patch
https://sourceware.org/ml/gdb-patches/2010-03/msg00605.html and the code
wasn't changed much since then.
This patch is to remove it.
gdb/gdbserver:
2016-04-28 Yao Qi <yao.qi@linaro.org>
* linux-low.h (struct lwp_info) <need_step_over>: Remove.
* linux-low.c (linux_wait_1): Update.
(need_step_over_p): Likewise.
This patch makes gdb_load_shlibs return the destination path of the
copied library. To make the procedure implementation and interface more
straightforward, it also changes it so that it accepts a single shared
library path at the time. Therefore, calls that are passed multiple
libraries:
gdb_load_shlibs $lib1 $lib2
must be changed to separate calls:
gdb_load_shlibs $lib1
gdb_load_shlibs $lib2
A subtle impact is the solib-search-path handling. In the former
version, solib-search-path is set using the directory of the first
passed lib (further calls overwrite the value). In the later version,
the directory of the library passed to the last call to gdb_load_shlibs
remnains. I don't think that's a problem in practice, since if we had
tests that needed multiple different paths in solib-search-path, they
wouldn't work in the first place.
Changed in v2:
* Split behavioural and rename changes in two separate patches.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_load_shlibs): Accept a single argument. Return
result of gdb_remote_download.
* gdb.base/ctxobj.exp: Split gdb_load_shlibs call.
* gdb.base/dso2dso.exp: Likewise.
* gdb.base/global-var-nested-by-dso.exp: Likewise.
* gdb.base/print-file-var.exp: Likewise.
* gdb.base/shlib-call.exp: Likewise.
* gdb.base/shreloc.exp: Likewise.
* gdb.base/solib-overlap.exp: Likewise.
* gdb.base/solib-weak.exp (do_test): Likewise.
* gdb.base/unload.exp: Likewise.
With current FSF GDB HEAD and old FSF gdbserver I expected I could do:
gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234'
(supplying that unsupported qXfer:exec-file:read by "file")
But that does not work because:
Sending packet: $vFile:setfs:0#bf...Packet received: OK
Packet vFile:setfs (hostio-setfs) is supported
...
Sending packet: $vFile:setfs:104#24...Packet received: OK
"target:/root/redhat/threadit": could not open as an executable file: Invalid argument
GDB documentation says:
The valid responses to Host I/O packets are:
An empty response indicates that this operation is not recognized.
This "empty response" vs. "OK" was a bug in gdbserver < 7.7. It was fixed by:
commit e7f0d979dd
Author: Yao Qi <yao@codesourcery.com>
Date: Tue Dec 10 21:59:20 2013 +0800
Fix a bug in matching notifications.
Message-ID: <1386684626-11415-1-git-send-email-yao@codesourcery.com>
https://sourceware.org/ml/gdb-patches/2013-12/msg00373.html
2013-12-10 Yao Qi <yao@codesourcery.com>
* notif.c (handle_notif_ack): Return 0 if no notification
matches.
with unpatched old FSF gdbserver and patched FSF GDB HEAD:
gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234'
Sending packet: $vFile:setfs:0#bf...Packet received: OK
Packet vFile:setfs (hostio-setfs) is NOT supported
...
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00007ffff7ddbae0 0x00007ffff7df627a Yes (*) target:/lib64/ld-linux-x86-64.so.2
0x00007ffff7bc48a0 0x00007ffff7bcf514 Yes (*) target:/lib64/libpthread.so.0
gdb/ChangeLog
2016-04-26 Jan Kratochvil <jan.kratochvil@redhat.com>
* remote.c (remote_start_remote): Detect PACKET_vFile_setfs.support.
I get a timeout fail in branch-to-self.exp when it is compiled by a
bare-mental target running qemu, which doesn't have signal.
The test should be skipped if gdb,nosignals exists, and that is
what this patch does.
gdb/testsuite:
2016-04-27 Yao Qi <yao.qi@linaro.org>
* gdb.base/branch-to-self.exp: Skip it if gdb,nosignals
exists.
Currently c_value_print will turn struct reference values into pointers before
doing a set of RTTI checks. This was introduced as a fix to PR c++/15401.
If there's RTTI the pointer will be adjusted and converted back to a reference.
However, if there's no RTTI the value will still be treated as a pointer during
the remainder of the function.
This patch moves the conversion down so that it's always performed when needed.
Notice this currently has not user-visible effects, so can be seen as a small
code cleanup. However, it'll be necessary for the bug-fix for handling
synthetic C++ references. It causes no testsuite regressions.
gdb/ChangeLog:
2016-04-26 Martin Galvan <martin.galvan@tallertechnologies.com>
* c-valprint.c (c_value_print): Always convert val back to reference
type if we converted it to a pointer type.
Hi,
command "tfind" will find the first trace snapshot if no trace
snapshot is selected, but this behavior isn't documented.
This patch completes the doc of command "tfind" without argument.
gdb/doc:
2016-04-27 Yao Qi <yao.qi@linaro.org>
* gdb.texinfo (tfind): Complete doc about tfind without
argument.
In some babeltrace versions before 1.2.0, the header file iterator.h
declares the enum values `BT_SEEK_*' within the struct declaration of
bt_iter_pos. The enum values are supposed to be globally-scoped, which
works for C, but not for C++. Later babeltrace versions declare the
enum outside the struct:
https://lists.lttng.org/pipermail/lttng-dev/2013-September/021411.html
Now that GDB is compiled with C++, the GDB build fails on a system with
an affected babeltrace version: the compiler complains about a missing
declaration of BT_SEEK_BEGIN in ctf.c.
This patch enhances the configure check to recognize such babeltrace
versions as unusable for GDB.
gdb/ChangeLog:
* configure.ac: Enhance configure check for babeltrace to reject
non-C++-enabled versions.
* configure: Regenerate.
Instead of pre-computing indices into a fortran array re-use
the value_* interfaces to subscript a fortran array.
The benefit of using the new interface is that it takes care of
dynamic types and resolve them when needed.
This fixes issues when printing structures with dynamic arrays from toplevel.
Before:
(gdb) p twov
$1 = ( (( ( 6352320, 0, -66, -1, 267) ( 343476, 1, -15, 1, 0) ( 5, 0, 5, 0, 1) ...
After:
(gdb) p twov
$1 = ( (( ( 1, 1, 1, 1, 1) ( 1, 1, 321, 1, 1) ( 1, 1, 1, 1, 1) ...
2016-04-26 Sanimir Agovic <sanimir.agovic@intel.com>
Keven Boell <keven.boell@intel.com>
Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Changelog:
* f-valprint.c (f77_create_arrayprint_offset_tbl): Remove
function.
(F77_DIM_SIZE, F77_DIM_OFFSET): Remove macro.
(f77_print_array_1): Use value_subscript to subscript a
value array.
(f77_print_array): Remove call to f77_create_arrayprint_offset_tbl.
(f_val_print): Use value_field to construct a field value.
gdb/testsuite/Changelog:
* vla-type.exp: Print structure from toplevel.
Resolve type of an array's element to be printed in case it is dynamic.
Otherwise we don't use the correct boundaries nor the right location.
Before:
ptype fivearr(1)
type = Type five
Type one
integer(kind=4) :: ivla(34196784:34196832,34197072:34197120,34197360:34197408)
End Type one :: tone
End Type five
After:
ptype fivearr(1)
type = Type five
Type one
integer(kind=4) :: ivla(2,4,6)
End Type one :: tone
End Type five
2016-04-26 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Changelog:
* valarith.c (value_address): Resolve dynamic types.
gdb/testsuite/Changelog:
* gdb.fortran/vla-type.f90: Add test for static and dynamic arrays
of dynamic types.
* gdb.fortran/vla-type.exp: Add test for static and dynamic arrays
of dynamic types.
Fortran supports dynamic types for which bounds, size and location
can vary during their lifetime. As a result of the dynamic
behaviour, they have to be resolved at every query.
This patch will resolve the type of a structure field when it
is dynamic.
2016-04-26 Bernhard Heckel <bernhard.heckel@intel.com>
2016-04-26 Keven Boell <keven.boell@intel.com>
Before:
(gdb) print threev%ivla(1)
Cannot access memory at address 0x3
(gdb) print threev%ivla(5)
no such vector element
After:
(gdb) print threev%ivla(1)
$9 = 1
(gdb) print threev%ivla(5)
$10 = 42
gdb/Changelog:
* NEWS: Add new supported features for fortran.
* gdbtypes.c (remove_dyn_prop): New.
(resolve_dynamic_struct): Keep type length for fortran structs.
* gdbtypes.h: Forward declaration of new function.
* value.c (value_address): Return dynamic resolved location of a value.
(set_value_component_location): Adjust the value address
for single value prints.
(value_primitive_field): Support value types with a dynamic location.
(set_internalvar): Remove dynamic location property of
internal variables.
gdb/testsuite/Changelog:
* gdb.fortran/vla-type.f90: New file.
* gdb.fortran/vla-type.exp: New file.
When GDBserver steps over a breakpoint using software single step, it
enqueues the signal, single step and deliver the signal in the next
resume if step over is not needed. In this way, the program won't
receive the signal if the conditional breakpoint is set a branch to
self instruction, because the step over is always needed.
This patch removes the restriction that don't deliver the signal to
the inferior if we are trying to reinsert a breakpoint for software
single step and change the decision on resume vs. step-over when the
LWP has pending signals to deliver.
gdb/gdbserver:
2016-04-25 Yao Qi <yao.qi@linaro.org>
* linux-low.c (lwp_signal_can_be_delivered): Adjust.
(need_step_over_p): Return zero if the LWP has pending signals
can be delivered on software single step target.
GDBserver steps over a breakpoint while the single step breakpoint
is inserted at the same address, there are two breakpoint objects
using single raw breakpoint, which is inserted (for single step).
When step over is finished, GDBserver reinsert the breakpoint, but
it finds the raw breakpoint is already inserted, and error out
"Breakpoint already inserted at reinsert time." Even if I change the
order to delete reinsert breakpoints first (which only decreases the
refcount, but leave inserted flag unchanged), the error is still
there.
The fix is to remove the error and return instead.
gdb/gdbserver:
2016-04-25 Yao Qi <yao.qi@linaro.org>
* linux-low.c (reinsert_raw_breakpoint): If bp->inserted is true
return instead of error.
When GDBserver inserts a breakpoint, it looks for raw breakpoint, if
the raw breakpoint is found, increase its refcount, and return. This
doesn't work when it steps over a breakpoint using software single
step and the underneath instruction of breakpoint is branch to self.
When stepping over a breakpoint on ADDR using software single step,
GDBserver uninsert the breakpoint, so the corresponding raw breakpoint
RAW's 'inserted' flag is zero. Then, GDBserver insert single step
breakpoint at the same address ADDR because the instruction is branch
to self, the same raw brekapoint RAW is found, and increase the
refcount. However, the raw breakpoint is not inserted, and the
program won't stop.
gdb/gdbserver:
2016-04-25 Pedro Alves <palves@redhat.com>
Yao Qi <yao.qi@linaro.org>
* mem-break.c (set_raw_breakpoint_at): Create a raw breakpoint
object. Insert it if it is not inserted yet. Increase the
refcount and link it into the proc's raw breakpoint list.
GDB doesn't insert software single step breakpoint if the instruction
branches to itself, so that the program can't stop after command "si".
(gdb) b 32
Breakpoint 2 at 0x8680: file git/gdb/testsuite/gdb.base/branch-to-self.c, line 32.
(gdb) c
Continuing.
Breakpoint 2, main () at gdb/git/gdb/testsuite/gdb.base/branch-to-self.c:32
32 asm (".Lhere: " BRANCH_INSN " .Lhere"); /* loop-line */
(gdb) si
infrun: clear_proceed_status_thread (Thread 3991.3991)
infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: step-over queue now empty
infrun: resuming [Thread 3991.3991] for step-over
infrun: skipping breakpoint: stepping past insn at: 0x8680
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sending packet: $Z0,8678,4#f3...Packet received: OK
infrun: skipping breakpoint: stepping past insn at: 0x8680
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sending packet: $Z0,b6fe86c8,4#82...Packet received: OK
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [Thread 3991.3991] at 0x868
breakpoint.c:should_be_inserted thinks the breakpoint shouldn't be
inserted, which is wrong. This patch restrict the condition that
only skip the non-single-step breakpoints if they are inserted at
the place we are stepping over, however we don't want to skip
single-step breakpoint if its thread is the thread we are stepping
over, so in this patch, I add a thread num in 'struct step_over_info'
to record the thread we're stepping over.
gdb:
2016-04-25 Yao Qi <yao.qi@linaro.org>
* breakpoint.c (should_be_inserted): Return 0 if the location's
owner is not single step breakpoint or single step breakpoint's
thread isn't the thread which is stepping past a breakpoint.
* gdbarch.sh (software_single_step): Update comments.
* gdbarch.h: Regenerated.
* infrun.c (struct step_over_info) <thread>: New field.
(set_step_over_info): New argument 'thread'. Callers updated.
(clear_step_over_info): Set field thread to -1.
(thread_is_stepping_over_breakpoint): New function.
* infrun.h (thread_is_stepping_over_breakpoint): Declaration.
gdb/ChangeLog
* ppc-linux-nat.c (ppc_linux_read_description): Use PPC_FEATURE_HAS_VSX
and PPC_FEATURE_HAS_ALTIVEC to check if such features are available.
I am seeing some test fails in gdb.trace/unavailable.exp on aarch64-linux,
like this,
print derived_whole^M
$43 = (Derived) {<Middle> = {<Base> = {x = 2}, _vptr.Middle = 0x401860 <VTT for Derived>, y = 3}, _vptr.Derived = 0x401848 <vtable for Derived+32>, z = 4}^M
(gdb) FAIL: gdb.trace/unavailable.exp: collect globals: print object on: print derived_whole
print derived_whole^M
$47 = {<Middle> = {<Base> = {x = 2}, _vptr.Middle = 0x401860 <VTT for Derived>, y = 3}, _vptr.Derived = 0x401848 <vtable for Derived+32>, z = 4}^M
(gdb) FAIL: gdb.trace/unavailable.exp: collect globals: print object off: print derived_whole
these fails are also found by recent x86_64-linux buildbot,
https://sourceware.org/ml/gdb-testers/2016-q2/msg00622.html
The fix is exactly the same as this one
http://www.sourceware.org/ml/gdb-patches/2015-10/msg00252.html (the
extra "VTT" after hex), in which we match extra things after $hex.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.trace/unavailable.exp (gdb_collect_globals_test_1): Match
more after $hex.
Before this patch
https://sourceware.org/ml/gdb-patches/2014-02/msg00709.html
read_value_memory checks parameter 'stack', and call read_stack or
read_memory respectively. However, 'stack' is not checked and
TARGET_OBJECT_MEMORY is always used in target_xfer_partial, which is
a mistake in the patch above.
This patch checks parameter 'stack', and choose TARGET_OBJECT_MEMORY
or TARGET_OBJECT_STACK_MEMORY accordingly.
gdb:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* valops.c (read_value_memory): New local variable 'stack'.
Set it to either TARGET_OBJECT_STACK_MEMORY or
TARGET_OBJECT_MEMORY.
This factors out all the yy-variables remapping to a single file,
instead of each parser having to do the same, with different prefixes.
With this, a parser just needs to define the prefix they want and
include yy-remap.h, which does the dirty job.
Note this renames the c_error, ada_error, etc. functions. Writing the
remapping pattern as:
#define yyerror GDB_YY_REMAP (error)
instead of:
#define yyerror GDB_YY_REMAP (yyerror)
would have avoided the renaming. However, that would be problematic
if we have a macro 'foo' in scope, when we write:
#define yyfoo GDB_YY_REMAP (foo)
as that would expand 'foo'.
The c_yyerror etc. naming end ups indicating that this is a yacc
related function more clearly, so feels like a good change, anyway.
gdb/ChangeLog:
2016-04-22 Pedro Alves <palves@redhat.com>
* ada-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* ada-lang.c (ada_language_defn): Adjust.
* ada-lang.h (ada_error): Rename to ...
(ada_yyerror): ... this.
* c-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* c-lang.c (c_language_defn, cplus_language_defn)
(asm_language_defn, minimal_language_defn): Adjust.
* c-lang.h (c_error): Rename to ...
(c_yyerror): ... this.
* d-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* d-lang.c (d_language_defn): Adjust.
* d-lang.h (d_error): Rename to ...
(d_yyerror): ... this.
* f-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* f-lang.c (f_language_defn): Adjust.
* f-lang.h (f_error): Rename to ...
(f_yyerror): ... this.
* go-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* go-lang.c (go_language_defn): Adjust.
* go-lang.h (go_error): Rename to ...
(go_yyerror): ... this.
* jv-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* jv-lang.c (java_language_defn): Adjust.
* jv-lang.h (java_error): Rename to ...
(java_yyerror): ... this.
* m2-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* m2-lang.c (m2_language_defn): Adjust.
* m2-lang.h (m2_error): Rename to ...
(m2_yyerror): ... this.
* objc-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* objc-lang.c (objc_language_defn): Adjust.
* opencl-lang.c (opencl_language_defn): Adjust.
* p-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* p-lang.c (pascal_language_defn): Adjust.
* p-lang.h (pascal_error): Rename to ...
(pascal_yyerror): ... this.
* yy-remap.h: New file.
The exceptions-across-readline issue was fixed by the previous commit.
Let's try this again.
gdb/ChangeLog:
2016-04-22 Pedro Alves <palves@redhat.com>
* common/common-exceptions.h (GDB_XCPT_TRY): Remove mention of
the foreign frames issue.
[__cplusplus] (GDB_XCPT): Define as GDB_XCPT_TRY.
If we map GDB'S TRY/CATCH macros to C++ try/catch, GDB breaks on
systems where readline isn't built with exceptions support. The
problem is that readline calls into GDB through the callback
interface, and if GDB's callback throws a C++ exception/error, the
system unwinder won't manage to unwind past the readline frame, and
ends up calling std::terminate(), which aborts the process:
(gdb) whatever-command-that-causes-an-error
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
Aborted
$
This went unnoticed for so long because:
- the x86-64 ABI requires -fasynchronous-unwind-tables, making it
possible for exceptions to cross readline with no special handling.
But e.g., on ARM or AIX, unless you build readline with
-fexceptions, you trip on the problem.
- TRY/CATCH was mapped to setjmp/longjmp, even in C++ mode, until
quite recently.
The fix is to catch and save any GDB exception that is thrown inside
the GDB readline callback, and then once the callback returns back to
the GDB code that called into readline in the first place, rethrow the
saved GDB exception.
This is similar in spirit to how we catch/map GDB exceptions at the
GDB/Python and GDB/Guile API boundaries.
The next question is then: if we intercept all exceptions within GDB's
readline callback, should we simply return normally to readline? The
callback prototype has no way to signal an error back to readline (*).
The answer is no -- if we return normally, we'll be returning to a
loop inside rl_callback_read_char that continues processing pending
input, calling into GDB again, redisplaying the prompt, etc. Thus if
we want to error out of rl_callback_read_char, we need to long jump
across it, just like we always did before TRY/CATCH were ever mapped
to C++ exceptions.
My first approach built a specialized API to handle this, with a
couple macros to hide the setjmp/longjmp and the struct gdb_exception
saving/rethrowing.
However, I realized that we need to:
- Handle multiple active rl_callback_read_char invocations. If,
while processing input something triggers a secondary prompt, we
end up in a nested rl_callback_read_char call, through
gdb_readline_wrapper.
- Propagate a struct gdb_exception along with the longjmp.
... and that this is exactly what the setjmp/longjmp-based TRY/CATCH
does.
So the fix makes the setjmp/longjmp TRY/CATCH always available under
new TRY_SJLJ/CATCH_SJLJ aliases, even when TRY/CATCH is mapped to C++
try/catch, and then uses TRY_SJLJ/CATCH_SJLJ to propagate GDB
exceptions across the readline callback.
This turns out to be a much better looking fix than my bespoke API
attempt, even. We'll probably be able to simplify TRY_SJLJ/CATCH_SJLJ
when we finally get rid of TRY/CATCH all over the tree, but until
then, this reuse seems quite nice for avoiding a second parallel
setjmp/longjmp mechanism.
(*) - maybe we could propose a readline API change, but we still need
to handle current readline, anyway.
gdb/ChangeLog:
2016-04-22 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (enum catcher_state, struct catcher)
(current_catcher): Define in C++ mode too.
(exceptions_state_mc_catch): Call throw_exception_sjlj instead of
throw_exception.
(throw_exception_sjlj, throw_exception_cxx): New functions,
factored out from throw_exception.
(throw_exception): Reimplement.
* common/common-exceptions.h (exceptions_state_mc_init)
(exceptions_state_mc_action_iter)
(exceptions_state_mc_action_iter_1, exceptions_state_mc_catch):
Declare in C++ mode too.
(TRY): Rename to ...
(TRY_SJLJ): ... this.
(CATCH): Rename to ...
(CATCH_SJLJ): ... this.
(END_CATCH): Rename to ...
(END_CATCH_SJLJ): ... this.
[GDB_XCPT == GDB_XCPT_SJMP] (TRY, CATCH, END_CATCH): Map to SJLJ
equivalents.
(throw_exception): Update comments.
(throw_exception_sjlj): Declare.
* event-top.c (gdb_rl_callback_read_char_wrapper): Extend intro
comment. Wrap body in TRY_SJLJ/CATCH_SJLJ and rethrow any
intercepted exception.
(gdb_rl_callback_handler): New function.
(gdb_rl_callback_handler_install): Always install
gdb_rl_callback_handler as readline callback.
Use the "gdb_rl_" prefix like other gdb readline function wrappers to
make it clear this is a gdb function, not a readline function.
gdb/ChangeLog:
2016-04-22 Pedro Alves <palves@redhat.com>
* event-top.c (rl_callback_read_char_wrapper): Rename to ...
(gdb_rl_callback_read_char_wrapper): ... this.
(change_line_handler, gdb_setup_readline): Adjust.
Bits 20 ~ 23 of CPSR are reserved (RAZ, read as zero), but they are not
zero if the arm program runs on aarch64-linux. AArch64 tracer gets PSTATE
from arm 32-bit tracee as CPSR, but bits 20 ~ 23 are used in PSTATE. I
think kernel should clear these bits when it is read through ptrace, but
the fix in user space is still needed.
This patch fixes these two fails,
-FAIL: gdb.reverse/insn-reverse.exp: ext_reg_push_pop: compare registers on insn 0:vldr d7, [r11, #-12]
-FAIL: gdb.reverse/insn-reverse.exp: ext_reg_push_pop: compare registers on insn 0:vldr d7, [r7]
gdb:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* aarch32-linux-nat.c (aarch32_gp_regcache_supply): Clear CPSR
bits 20 to 23.
gdb/gdbserver:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* linux-aarch32-low.c (arm_store_gregset): Clear CPSR bits 20
to 23.
Hi,
I am seeing the fail below on aarch64-linux with gcc 4.9.2,
break main
Breakpoint 1 at 0x4006e8: file binutils-gdb/gdb/testsuite/gdb.base/annota1.c, line 14.^M
(gdb) FAIL: gdb.base/annota1.exp: breakpoint main
the test expects the breakpoint is set on line 15. Let us look at
the main function,
12 int
13 main (void)
14 {
15 int my_array[3] = { 1, 2, 3 }; /* break main */
16
17 value = 7;
18
19 #ifdef SIGUSR1
20 signal (SIGUSR1, handle_USR1);
21 #endif
(gdb) disassemble main
Dump of assembler code for function main:
0x00000000004006e0 <+0>: stp x29, x30, [sp,#-48]!
0x00000000004006e4 <+4>: mov x29, sp
0x00000000004006e8 <+8>: adrp x0, 0x411000 <signal@got.plt>
0x00000000004006ec <+12>: add x0, x0, #0x40
the breakpoint is set on the right address after skipping prologue, but
0x00000000004006e8 is mapped to the line 14, as shown below,
(gdb) maintenance info line-table
objfile: /home/yao.qi/source/build-aarch64/gdb/testsuite/outputs/gdb.base/annota1/annota1 ((struct objfile *) 0x2b0e1850)
compunit_symtab: ((struct compunit_symtab *) 0x2b0ded50)
symtab: /home/yao.qi/source/binutils-gdb/gdb/testsuite/gdb.base/annota1.c ((struct symtab *) 0x2b0dedd0)
linetable: ((struct linetable *) 0x2b12c8b0):
INDEX LINE ADDRESS
0 7 0x00000000004006d0
1 8 0x00000000004006d8
2 14 0x00000000004006e0
3 14 0x00000000004006e8
4 15 0x00000000004006fc
so GDB does nothing wrong. Program hits breakpoint on either line 14
or line 15 is right to me. With anther gcc (4.9.3), the line-table looks
correct, and no test fail. Instead of setting breakpoint on main and
assuming the line is what we get from the source, we can set breakpoint
on that line. On the other hand, the test prints the values of the
array and check, so we need to set breakpoint on the line setting the
values of array and "next", rather than setting the breakpoint on main.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.base/annota1.exp: Set breakpoint on line $main_line.
* gdb.base/annota3.exp: Likewise.
Simple exchange of mpx-avx for avx-mpx.
Other occurrences were not found.
2016-04-22 Walfred Tedeschi <walfred.tedeschi@intel.com>
gdb/gdbserver/ChangeLog:
* configure.srv (srv_amd64_xmlfiles): Exchange
i386/amd64-mpx-avx.xml for i386/amd64-avx-mpx.xml.
I see the following test fail in arm-linux with -marm and -fomit-frame-pointer,
step
callee () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/step-reverse.c:27
27 } /* RETURN FROM CALLEE */
(gdb) step
main () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/step-reverse.c:58
58 callee(); /* STEP INTO THIS CALL */
(gdb) FAIL: gdb.reverse/step-precsave.exp: reverse step into fn call
As we can see, the "step" has already stepped into the function callee,
but in the last line. The second "step" attempts to step to function
body, but it goes out of callee, which isn't expected.
The program is compiled with -marm and -fomit-frame-pointer, the
function callee is prologue-less, because nothing needs to be saved
on stack,
(gdb) disassemble callee
Dump of assembler code for function callee:
0x00010680 <+0>: movw r3, #2364 ; 0x93c
0x00010684 <+4>: movt r3, #2
0x00010688 <+8>: ldr r3, [r3]
0x0001068c <+12>: add r2, r3, #1
0x00010690 <+16>: movw r3, #2364 ; 0x93c
0x00010694 <+20>: movt r3, #2
0x00010698 <+24>: str r2, [r3]
0x0001069c <+28>: mov r3, #0
0x000106a0 <+32>: mov r0, r3
0x000106a4 <+36>: bx lr
program stops at the 0x106a0 (passed the epilogue) after the first
"step". When second "step" is executed, the stepping range is
[0x10680-0x106a0], which starts from the first instruction of function
callee (because it doesn't have prologue).
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [LWP 2461] at 0x1069c^M
infrun: prepare_to_wait^M
infrun: target_wait (-1.0.0, status) =^M
infrun: 2461.2461.0 [LWP 2461],^M
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP^M
infrun: TARGET_WAITKIND_STOPPED^M
infrun: stop_pc = 0x10698^M
infrun: stepping inside range [0x10680-0x106a0]
When program goes out of the range, it stops at the caller of callee,
and test fails. IOW, if function callee has prologue, the stepping
range won't start from the first instruction of the function, and
program stops at the prologue and test passes.
IMO, GDB does nothing wrong, but test shouldn't expect the program
stops in callee after the second "step". I decide to fix test rather
than GDB. In this patch, I change to test to do one "step", and check
the program is still in callee, then, do multiple "step" until program
goes out of the callee.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.reverse/step-precsave.exp: Do one step and test program
stops in "callee" and do multiple steps until program goes out
of "callee".
* gdb.reverse/step-reverse.exp: Likewise.
GDBserver doesn't deliver signal when stepping over a breakpoint even
hardware single step is used. When GDBserver started to step over
(thread creation) breakpoint for mutlit-threaded debugging in 2002 [1],
GDBserver behaves this way.
This behavior gets trouble on conditional breakpoints on branch to
self instruction like this,
0x00000000004005b6 <+29>: jmp 0x4005b6 <main+29>
and I set breakpoint
$(gdb) break branch-to-self.c:43 if counter > 3
and the variable counter will be set to 5 in SIGALRM signal handler.
Since GDBserver keeps stepping over breakpoint, the SIGALRM can never
be dequeued and delivered to the inferior, so the program can't stop.
The test can be found in gdb.base/branch-to-self.exp.
GDBserver didn't deliver signal when stepping over a breakpoint because
a tracepoint is collected twice if GDBserver does so in the following
scenario, which can be reproduced by gdb.trace/signal.exp.
- program stops at tracepoint, and tracepoint is collected,
- gdbserver starts a step-over,
- a signal arrives, step-over is canceled, and signal should be passed,
- gdbserver starts a new step-over again, pass the signal as well,
- program stops at the entry of signal handler, step-over finished,
- gdbserver proceeds,
- program returns from the signal handler, again to the tracepoint,
and thus is collected again.
The spurious collection isn't that harmful, IMO, so it should be OK
to let GDBserver deliver signal when stepping over a breakpoint.
gdb/gdbserver:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* linux-low.c (lwp_signal_can_be_delivered): Don't deliver
signal when stepping over breakpoint with software single
step.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.trace/signal.exp: Also pass if
$tracepoint_hits($i) > $iterations.
This is to test whether GDBserver deliver signal to the inferior while
doing the step over. Nowadays, GDBserver doesn't deliver signal, so
there won't be spurious collection, however, if GDBserver does deliver
signal, there might be spurious collection.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.trace/signal.c: New file.
* gdb.trace/signal.exp: New file.
Set the number of registers for non-XML-described Linux targets to 90,
reverting a change made here with the addition of DSP register support:
commit 1faeff088b
Author: Maciej W. Rozycki <macro@linux-mips.org>
Date: Thu Mar 1 22:19:48 2012 +0000
and fixing a regression introduced for legacy `gdbserver' targets
causing a "Remote 'g' packet reply is too long" error message where the
amount of register data received with a `g' packet (90) exceeds the
maximum number of registers expected (79).
Update the setting for XML-described targets, reflecting the actual
number of registers which have been assigned numbers, matching the:
gdb_assert (gdbarch_num_regs (gdbarch) <= MIPS_RESTART_REGNUM);
requirement in `mips_linux_init_abi'.
gdb/
* mips-tdep.c (mips_gdbarch_init): For GDB_OSABI_LINUX set
`num_regs' to 90 rather than 79. Where a target description is
present adjust the setting appropriately.
We don't currently handle the case of gdb's readline callback throwing
gdb C++ exceptions across a readline that wasn't built with
-fexceptions. The end result is:
(gdb) whatever-command-that-causes-an-error
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
Aborted
$
Until that is fixed, revert back to sjlj-based exceptions again.
gdb/ChangeLog:
2016-04-21 Pedro Alves <palves@redhat.com>
* common/common-exceptions.h (GDB_XCPT_TRY): Add comment.
(GDB_XCPT): Always define as GDB_XCPT_SJMP.
We currently get:
../../src/gdb/aix-thread.c: In function 'int pdc_read_data(pthdb_user_t, void*, pthdb_addr_t, size_t)':
../../src/gdb/aix-thread.c:465:46: error: invalid conversion from 'void*' to 'gdb_byte* {aka unsigned char*}' [-fpermissive]
status = target_read_memory (addr, buf, len);
^
../../src/gdb/aix-thread.c: In function 'void aix_thread_resume(target_ops*, ptid_t, int, gdb_signal)':
../../src/gdb/aix-thread.c:1010:46: error: invalid conversion from 'void*' to 'int*' [-fpermissive]
gdb_signal_to_host (sig), (void *) tid);
^
../../src/gdb/aix-thread.c:243:1: error: initializing argument 5 of 'int ptrace64aix(int, int, long long int, int, int*)' [-fpermissive]
ptrace64aix (int req, int id, long long addr, int data, int *buf)
../../src/gdb/rs6000-nat.c: In function 'gdb_byte* rs6000_ptrace_ldinfo(ptid_t)':
../../src/gdb/rs6000-nat.c:596:36: error: invalid conversion from 'void*' to 'gdb_byte* {aka unsigned char*}' [-fpermissive]
gdb_byte *ldi = xmalloc (ldi_size);
^
../../src/gdb/rs6000-nat.c:615:36: error: invalid conversion from 'void*' to 'gdb_byte* {aka unsigned char*}' [-fpermissive]
ldi = xrealloc (ldi, ldi_size);
^
(and more instances of the same).
gdb/ChangeLog:
2016-04-21 Pedro Alves <palves@redhat.com>
* aix-thread.c (pdc_read_data, pdc_write_data): Add cast.
(aix_thread_resume): Use PTRACE_TYPE_ARG5.
* rs6000-nat.c (rs6000_ptrace64): Use PTRACE_TYPE_ARG5.
(rs6000_ptrace_ldinfo): Change type of 'ldi' local to void
pointer, and cast return to gdb_byte pointer.
Now that gdb/gdbserver compile as C++ programs by default, the s390
GNU/Linux build started failing with:
In file included from ../../src/gdb/common/common-defs.h:64:0,
from ../../src/gdb/defs.h:28,
from ../../src/gdb/s390-linux-nat.c:22:
../../src/gdb/s390-linux-nat.c: In function ‘void fetch_regset(regcache*, int, int, int, const regset*)’:
../../src/gdb/../include/libiberty.h:711:38: error: invalid conversion from ‘void*’ to ‘gdb_byte* {aka unsigned char*}’ [-fpermissive]
# define alloca(x) __builtin_alloca(x)
^
../../src/gdb/s390-linux-nat.c:297:19: note: in expansion of macro ‘alloca’
gdb_byte *buf = alloca (regsize);
^
etc.
gdb/ChangeLog:
2016-04-21 Pedro Alves <palves@redhat.com>
* s390-linux-nat.c (fetch_regset, store_regset, check_regset): Use
void * instead of gdb_byte *.
gdb/gdbserver/ChangeLog:
2016-04-21 Pedro Alves <palves@redhat.com>
* linux-s390-low.c (s390_collect_ptrace_register)
(s390_supply_ptrace_register, s390_get_hwcap): Use gdb_byte * and
add casts.
(s390_check_regset): Use void * instead of gdb_byte *.
This makes --enable-build-with-cxx be "yes" by default.
One must now configure with --enable-build-with-cxx=no in order to
build with a C compiler.
gdb/ChangeLog:
2016-04-20 Pedro Alves <palves@redhat.com>
* build-with-cxx.m4 (GDB_AC_BUILD_WITH_CXX): Default to yes.
* configure: Renegerate.
gdb/gdbserver/ChangeLog:
2016-04-20 Pedro Alves <palves@redhat.com>
* configure: Renegerate.
Building in C++ mode caught a bug here:
.../src/gdb/darwin-nat.c: In function 'ptid_t darwin_decode_message(mach_msg_header_t*, darwin_thread_t**, inferior**, target_waitstatus*)':
.../src/gdb/darwin-nat.c:1016:25: error: invalid conversion from 'int' to 'gdb_signal' [-fpermissive]
status->value.sig = WTERMSIG (wstatus);
^
gdb/ChangeLog:
2016-04-20 Pedro Alves <palves@redhat.com>
* darwin-nat.c (darwin_decode_message): Use gdb_signal_from_host.
Fixes, with x86_64-apple-darwin15-gcc (gcc 5.3.0):
.../src/gdb/aarch64-tdep.c: In function 'aarch64_record_load_store':
.../src/gdb/aarch64-tdep.c:3479:67: error: passing argument 3 of 'regcache_raw_read_unsigned' from incompatible pointer type [-Werror=incompatible-pointer-types]
bits (aarch64_insn_r->aarch64_insn, 16, 20), ®_rm_val);
^
In file included from .../src/gdb/regcache.h:23:0,
from .../src/gdb/gdbarch.h:69,
from .../src/gdb/defs.h:620,
from .../src/gdb/aarch64-tdep.c:21:
.../src/gdb/common/common-regcache.h:60:29: note: expected 'ULONGEST * {aka long unsigned int *}' but argument is of type 'uint64_t * {aka long long unsigned int *}'
extern enum register_status regcache_raw_read_unsigned
^
gdb/ChangeLog:
2016-04-20 Pedro Alves <palves@redhat.com>
* aarch64-tdep.c (aarch64_record_load_store): Change type of
'reg_rm_val' local to ULONGEST.
Fixes, with gcc 5.3.0:
.../src/gdb/darwin-nat.c: In function 'void darwin_resume_thread(inferior*, darwin_thread_t*, int, int)':
.../src/gdb/darwin-nat.c:731:21: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
(caddr_t)thread->gdb_port, nsignal);
^
.../src/gdb/darwin-nat.c:84:35: note: in definition of macro 'PTRACE'
darwin_ptrace(#CMD, CMD, (PID), (ADDR), (SIG))
^
thread->gdb_port is an unsigned int, caddr_t is a void pointer.
gdb/ChangeLog:
2016-04-20 Pedro Alves <palves@redhat.com>
* darwin-nat.c (darwin_resume_thread): Add uintptr_t cast.
Fix the compilation failure by including arch/arm-linux.h in
aarch32-linux-nat.c.
gdb:
2016-04-20 Yao Qi <yao.qi@linaro.org>
* aarch32-linux-nat.c: Include "arch/arm-linux.h".
This patch moves macro ARM_CPSR_GREGNUM to arch/arm-linux.h so that it
can be used in GDBserver side.
gdb:
2016-04-20 Yao Qi <yao.qi@linaro.org>
* arm-linux-tdep.h (ARM_CPSR_GREGNUM): Move it to ...
* arch/arm-linux.h: ... here.
gdb/gdbserver:
2016-04-20 Yao Qi <yao.qi@linaro.org>
* linux-aarch32-low.c: Include "arch/arm-linux.h".
(arm_fill_gregset): Use ARM_CPSR_GREGNUM rather than magic
number 16.
(arm_store_gregset): Likewise.
FreeBSD versions older than 11.0 use char * as the type of ss_sp in
stack_t instead of the standards-defined void *. C++ allows a char *
pointer to be converted to a void *, so it is safe to cast the return
value of xmalloc to char * if ss_sp is either a char * or void *.
Just always use the cast to char * since that is less ugly than having
to add a special case.
gdb/ChangeLog:
* main.c (setup_alternate_signal_stack): Cast to char *.
In record_linux_system_call there are some cases with identical
handling. These are merged together to reduce code duplication.
gdb/ChangeLog:
* linux-record.c (record_linux_system_call): Merge handling for
readlink/recv/read and pipe/pipe2.
In the previous patch a new set of target descriptions
(i386|amd64)-avx-mpx were added being same as the (i386|amd64)-mpx.
This patch removes AVX feature from (i386|amd64)-mpx target
description set.
This way the (i386|amd64)avx_mpx(_linux|) set has AVX and MPX features
and (i386|amd64)mpx(_linux|) only MPX.
2016-04-14 Walfred Tedeschi <walfred.tedeschi@intel.com>
* features/i386/amd64-mpx-linux.xml: Remove AVX feature.
* features/i386/amd64-mpx.xml: Remove AVX feature.
* features/i386/i386-mpx-linux.xml: Remove AVX feature.
* features/i386/i386-mpx.xml: Remove AVX feature.
* features/i386/amd64-mpx-linux.c: Regenerate.
* features/i386/amd64-mpx.c: Regenerate.
* features/i386/i386-mpx-linux.c: Regenerate.
* features/i386/i386-mpx.c: Regenerate.
* regformats/i386/amd64-mpx-linux.dat: Regenerate.
* regformats/i386/amd64-mpx.dat: Regenerate.
* regformats/i386/i386-mpx-linux.dat: Regenerate.
* regformats/i386/i386-mpx.dat: Regenerate.
The current MPX target descriptions assume that MPX is always combined
with AVX, however that's not correct. We can have machines with MPX
and without AVX; or machines with AVX and without MPX.
This patch adds new target descriptions for machines that support
both MPX and AVX, as duplicates of the existing MPX descriptions.
The following commit will remove AVX from the MPX-only descriptions.
2016-04-16 Walfred Tedeschi <walfred.tedeschi@intel.com>
gdb/ChangeLog:
* amd64-linux-tdep.c (features/i386/amd64-avx-mpx-linux.c):
New include.
(amd64_linux_core_read_description): Add case for
X86_XSTATE_AVX_MPX_MASK.
(_initialize_amd64_linux_tdep): Call initialize_tdesc_amd64_avx_mpx_linux.
* amd64-linux-tdep.h (tdesc_amd64_avx_mpx_linux): New definition.
* amd64-tdep.c (features/i386/amd64-avx-mpx.c): New include.
(amd64_target_description): Add case for X86_XSTATE_AVX_MPX_MASK.
(_initialize_amd64_tdep): Call initialize_tdesc_amd64_avx_mpx.
* common/x86-xstate.h (X86_XSTATE_MPX_MASK): Remove AVX bits.
(X86_XSTATE_AVX_MPX_MASK): New case.
* features/Makefile (i386/i386-avx-mpx, i386/i386-avx-mpx-linux)
(i386/amd64-avx-mpx, i386/amd64-avx-mpx-linux): New rules.
(i386/i386-avx-mpx-expedite, i386/i386-avx-mpx-linux-expedite)
(i386/amd64-avx-mpx-expedite, i386/amd64-avx-mpx-linux-expedite):
New expedites.
* i386-linux-tdep.c (features/i386/i386-avx-mpx-linux.c): New
include.
(i386_linux_core_read_description): Add case
X86_XSTATE_AVX_MPX_MASK.
(_initialize_i386_linux_tdep): Call
initialize_tdesc_i386_avx_mpx_linux.
* i386-linux-tdep.h (tdesc_i386_avx_mpx_linux): New include.
* i386-tdep.c (features/i386/i386-avx-mpx.c): New include.
(i386_target_description): Add case for X86_XSTATE_AVX_MPX_MASK.
* x86-linux-nat.c (x86_linux_read_description): Add case for
X86_XSTATE_AVX_MPX_MASK.
* features/i386/amd64-avx-mpx-linux.xml: New file.
* features/i386/i386-avx-mpx-linux.xml: New file.
* features/i386/i386-avx-mpx.xml: New file.
* features/i386/amd64-avx-mpx.xml: New file.
* features/i386/amd64-avx-mpx-linux.c: Generated.
* features/i386/amd64-avx-mpx.c: Generated.
* features/i386/i386-avx-mpx-linux.c: Generated.
* features/i386/i386-avx-mpx.c: Generated.
* regformats/i386/amd64-avx-mpx-linux.dat: Generated.
* regformats/i386/amd64-avx-mpx.dat: Generated.
* regformats/i386/i386-avx-mpx-linux.dat: Generated.
* regformats/i386/i386-avx-mpx.dat: Generated.
gdb/gdbserver/ChangeLog:
* Makefile.in (clean): Add removal for i386-avx-mpx.c,
i386-avx-mpx-linux.c, amd64-avx-mpx.c and amd64-avx-mpx-linux.c.
(i386-avx-mpx.c, i386-avx-mpx-linux.c, amd64-avx-mpx.c)
(amd64-avx-mpx-linux.c): New rules.
(amd64-avx-mpx-linux-ipa.o, i386-avx-mpx-linux-ipa.o): New rule.
* configure.srv (srv_i386_regobj): Add i386-avx-mpx.o.
(srv_i386_linux_regobj): Add i386-avx-mpx-linux.o.
(srv_amd64_regobj): Add amd64-avx-mpx.o.
(srv_amd64_linux_regobj): Add amd64-avx-mpx-linux.o.
(srv_i386_xmlfiles): Add i386/i386-avx-mpx.xml.
(srv_amd64_xmlfiles): Add i386/amd64-avx-mpx.xml.
(srv_i386_linux_xmlfiles): Add i386/i386-avx-mpx-linux.xml.
(srv_amd64_linux_xmlfiles): Add i386/amd64-avx-mpx-linux.xml.
(ipa_i386_linux_regobj): Add i386-avx-mpx-linux-ipa.o.
(ipa_amd64_linux_regobj): Add amd64-avx-mpx-linux-ipa.o.
* linux-x86-low.c (x86_linux_read_description): Add case for
X86_XSTATE_AVX_MPX_MASK.
(x86_get_ipa_tdesc_idx): Add cases for avx_mpx.
(initialize_low_arch): Call init_registers_amd64_avx_mpx_linux and
init_registers_i386_avx_mpx_linux.
* linux-i386-ipa.c (get_ipa_tdesc): Add case for avx_mpx.
(initialize_low_tracepoint): Call
init_registers_i386_avx_mpx_linux.
* linux-amd64-ipa.c (get_ipa_tdesc): Add case for avx_mpx.
(initialize_low_tracepoint): Call
init_registers_amd64_avx_mpx_linux.
* linux-x86-tdesc.h (X86_TDESC_AVX_MPX): New enum value.
(init_registers_amd64_avx_mpx_linux, tdesc_amd64_avx_mpx_linux)
(init_registers_i386_avx_mpx_linux, tdesc_i386_avx_mpx_linux): New
declarations.
The ptrace args/return types detection doesn't work properly in C++
mode, on non-GNU/Linux hosts. For example, on gcc70 (NetBSD 5.1),
where the prototype is:
int ptrace(int, __pid_t, void*, int);
configure misdetects it as:
$ grep PTRACE_TYPE config.h
#define PTRACE_TYPE_ARG1 int
#define PTRACE_TYPE_ARG3 int *
#define PTRACE_TYPE_ARG4 int
/* #undef PTRACE_TYPE_ARG5 */
#define PTRACE_TYPE_RET int
resulting in:
../../src/gdb/amd64bsd-nat.c: In function 'void amd64bsd_fetch_inferior_registers(target_ops*, regcache*, int)':
../../src/gdb/amd64bsd-nat.c:56: warning: dereferencing type-punned pointer will break strict-aliasing rules
../../src/gdb/amd64bsd-nat.c: In function 'void amd64bsd_store_inferior_registers(target_ops*, regcache*, int)':
../../src/gdb/amd64bsd-nat.c:104: warning: dereferencing type-punned pointer will break strict-aliasing rules
../../src/gdb/amd64bsd-nat.c:110: warning: dereferencing type-punned pointer will break strict-aliasing rules
We could address this [1], however despite ptrace.m4's claim:
# Needs to be tested in C++ mode, to detect whether we need to cast
# the first argument to enum __ptrace_request.
it appears that there's actually no need to test in C++ mode. Always
running the ptrace tests in C mode works just the same on GNU/Linux.
I remember experimenting with several different ways to handle the
original issue back then, and maybe that was needed in some other
attempt and then I didn't realize it ended up not really necessary.
Confirmed that this fixes the NetBSD 5.1 C++ build, and confirmed that
C and C++ builds on Fedora 23 are unaffected.
[1] - https://sourceware.org/ml/gdb-patches/2016-04/msg00374.html
gdb/ChangeLog:
2016-04-18 Pedro Alves <palves@redhat.com>
* ptrace.m4 (GDB_AC_PTRACE): Don't run tests in C++ mode.
* configure: Regenerate.
gdb/gdbserver/ChangeLog:
2016-04-18 Pedro Alves <palves@redhat.com>
* configure: Regenerate.
After compiling a program which uses C++ references some optimizations may
convert the references into synthetic "pointers". Trying to print the address
of one of such synthetic references causes gdb to crash with the following
error:
(gdb) print &ref
/build/buildd/gdb-7.7.1/gdb/dwarf2loc.c:1624: internal-error: Should not be able to create a lazy value with an enclosing type
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Apparently, what was causing it was that value_addr returns a copy of the value
that represents the reference with its type set to T* instead of T&. However,
its enclosing_type is left untouched, which fails a check made in
read_pieced_value. We only see the crash happen for references that are
synthetic because they're treated as pieced values, thus the call to
read_pieced_value.
On a related note, it seems that in general there are all sorts of breakage
when working with synthetic references. This is reported here:
https://sourceware.org/bugzilla/show_bug.cgi?id=19893
gdb/ChangeLog:
2016-04-18 Martin Galvan <martin.galvan@tallertechnologies.com>
* valops.c (value_addr): For C++ references, set the copied value's
enclosing_type as well.
gdb/testsuite/ChangeLog:
2016-04-18 Martin Galvan <martin.galvan@tallertechnologies.com>
* gdb.dwarf2/implref.exp: New file.
Gfortran and ifort have different names for data types. Encapsulate
type names in a library to increase number of supported compilers.
gfortran -4.2 : int4
gfortran>=4.3 : integer(kind=4)
ifort : INTEGER(4)
2016-04-18 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/testsuite/Changelog:
* gdb.fortran/common-block.exp: Use type naming defined in lib fortran.
* gdb.fortran/derived-type.exp: Use type naming defined in lib fortran.
* gdb.fortran/multi-dim.exp: Use type naming defined in lib fortran.
* gdb.fortran/vla-datatypes.exp: Use type naming defined in lib fortran.
* gdb.fortran/vla-ptype-sub.exp: Use type naming defined in lib fortran.
* gdb.fortran/vla-ptype.exp: Use type naming defined in lib fortran.
* gdb.fortran/whatis_type.exp: Use type naming defined in lib fortran.
* lib/fortran.exp (fortran_int4): New procedure.
(fortran_real4, fortran_real8, fortran_complex4): Likewise.
(fortran_logical4): Likewise.
We are missing "-fpic" flag when compiling shared libraries with ICC.
2016-04-18 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Testsuite/Changelog:
* lib/gdb.exp (gdb_compile_shlib): Add flag for ICC compiler.
Add Intel specific preprocessor macros to query the version of the compiler.
2016-04-18 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Testsuite/Changelog:
* lib/compiler.c: Add Intel specific preprocessor macros.
* lib/compiler.cc: Likewise.
2016-04-18 Yao Qi <yao.qi@linaro.org>
Revert:
2016-04-15 Yao Qi <yao.qi@linaro.org>
* arm-tdep.c (thumb_stack_frame_destroyed_p): Return zero if
PC is far from the end of function.
On:
$ uname -a
NetBSD gcc70.fsffrance.org 5.1 NetBSD 5.1 (GENERIC) #0: Sat Nov 6 13:19:33 UTC 2010 builds@b6.netbsd.org:/home/builds/ab/netbsd-5-1-RELEASE/amd64/201011061943Z-obj/home/builds/ab/netbsd-5-1-RELEASE/src/sys/arch/amd64/compile/GENERIC amd64
The link fails with:
(...)
d-exp.o: In function `parse_number':
../../src/gdb/d-exp.y:762: multiple definition of `yydefred'
ada-exp.o:/home/palves/gdb/build/gdb/ada-lex.c:925: first defined here
ld: Warning: size of symbol `yydefred' changed from 464 in ada-exp.o to 336 in d-exp.o
Makefile:1404: recipe for target 'gdb' failed
NetBSD's yacc uses a "yydefred" symbol that we missed renaming in the
Ada parser. All other gdb parsers do this already.
gdb/ChangeLog:
2016-04-16 Pedro Alves <palves@redhat.com>
* ada-exp.y (yydefred): Define as ada_yydefred.
Compiling gdb with --enable-build-with-cxx --disable-nls, we get:
.../src/gdb/ada-lang.c:7657:16: error: invalid conversion from ‘const char*’ to ‘char*’ [-fpermissive]
type_str = (type != NULL
^
In file included from .../src/gdb/common/common-defs.h:67:0,
from .../src/gdb/defs.h:28,
from .../src/gdb/ada-lang.c:21:
.../src/gdb/common/gdb_locale.h:40:27: error: invalid conversion from ‘const char*’ to ‘char*’ [-fpermissive]
# define _(String) (String)
^
.../src/gdb/ada-lang.c:7730:46: note: in expansion of macro ‘_’
char *name_str = name != NULL ? name : _("<null>");
^
Makefile:1140: recipe for target 'ada-lang.o' failed
gdb/ChangeLog:
2016-04-15 Pedro Alves <palves@redhat.com>
* ada-lang.c (ada_lookup_struct_elt_type): Constify 'type_str' and
'name_str' locals.
With libipt's headers installed, a build with --enable-build-with-cxx
fails with:
.../src/gdb/btrace.c: In function ‘btrace_insn_flag pt_btrace_insn_flags(const pt_insn*)’:
.../src/gdb/btrace.c:734:33: error: invalid conversion from ‘int’ to ‘btrace_insn_flag’ [-fpermissive]
enum btrace_insn_flag flags = 0;
^
.../src/gdb/btrace.c:737:11: error: invalid conversion from ‘int’ to ‘btrace_insn_flag’ [-fpermissive]
flags |= BTRACE_INSN_FLAG_SPECULATIVE;
^
gdb/ChangeLog:
2016-04-15 Pedro Alves <palves@redhat.com>
* btrace.c (pt_btrace_insn_flags): Change return type to
btrace_insn_flags. Use btrace_insn_flags for local.
This makes the MIPS Linux backends recognize TRAP_BRKPT and
TRAP_HWBKPT in siginfo.si_code in addition to SI_KERNEL, since Linux
4.6 now reports the finer-grained si_code values too.
Refs:
https://sourceware.org/ml/gdb-patches/2016-02/msg00756.htmlhttps://sourceware.org/ml/gdb-patches/2016-04/msg00090.html
On kernels that report SI_KERNEL (<= 4.5), we'll enter the "ambiguous"
path of save_stop_reason:
if (GDB_ARCH_IS_TRAP_BRKPT (siginfo.si_code)
&& GDB_ARCH_IS_TRAP_HWBKPT (siginfo.si_code))
{
/* The si_code is ambiguous on this arch -- check debug
registers. */
if (!check_stopped_by_watchpoint (lp))
lp->stop_reason = TARGET_STOPPED_BY_SW_BREAKPOINT;
}
while on kernels that report the finer-grained si_code values (>= 4.6),
we'll enter the corresponding branches:
else if (GDB_ARCH_IS_TRAP_BRKPT (siginfo.si_code))
{
}
else if (GDB_ARCH_IS_TRAP_HWBKPT (siginfo.si_code))
{
...
gdb/ChangeLog:
2016-04-15 Pedro Alves <palves@redhat.com>
* nat/linux-ptrace.h [__mips__] (GDB_ARCH_IS_TRAP_BRKPT): Also
accept TRAP_BRKPT.
[__mips__] (GDB_ARCH_IS_TRAP_HWBKPT): Also accept TRAP_HWBKPT.
thumb_stack_frame_destroyed_p scans the instructions from PC to the
end of the function, but if PC is far from the end of pc, we don't
have to scan, because PC should be in epilogue if it is still
far from the end of the function. The criterion I use here is 16
bytes, which is more than 4 instructions.
Regression tested on aarch64-linux with mutli-arch debug.
gdb:
2016-04-15 Yao Qi <yao.qi@linaro.org>
* arm-tdep.c (thumb_stack_frame_destroyed_p): Return zero if
PC is far from the end of function.
On:
$ uname -a
NetBSD gcc70.fsffrance.org 5.1 NetBSD 5.1 (GENERIC) #0: Sat Nov 6 13:19:33 UTC 2010 builds@b6.netbsd.org:/home/builds/ab/netbsd-5-1-RELEASE/amd64/201011061943Z-obj/home/builds/ab/netbsd-5-1-RELEASE/src/sys/arch/amd64/compile/GENERIC amd64
With:
$ g++ -v
Using built-in specs.
Target: x86_64--netbsd
Configured with: /usr/src/tools/gcc/../../gnu/dist/gcc4/configure --enable-long-long --disable-multilib --enable-threads --disable-symvers --build=x86_64-unknown-netbsd4.99.72 --host=x86_64--netbsd --target=x86_64--netbsd --enable-__cxa_atexit
Thread model: posix
gcc version 4.1.3 20080704 prerelease (NetBSD nb2 20081120)
I saw:
cc1plus: warnings being treated as errors
../../src/gdb/ctf.c: In function 'void ctf_save_metadata_header(trace_write_handler*)':
../../src/gdb/ctf.c:267: warning: format not a string literal, argument types not checked
cc1plus: warnings being treated as errors
../../src/gdb/cli/cli-cmds.c: In function 'void alias_command(char*, int)':
../../src/gdb/cli/cli-cmds.c:1428: warning: format not a string literal and no format arguments
../../src/gdb/cli/cli-cmds.c:1457: warning: format not a string literal and no format arguments
gdb/ChangeLog:
2016-04-14 Pedro Alves <palves@redhat.com>
* cli/cli-cmds.c (alias_usage_error): New function.
(alias_command): Use it.
* ctf.c (ctf_save_metadata_header): Inline metadata_fmt local in
ctf_save_write_metadata call.
On:
$ uname -a
NetBSD gcc70.fsffrance.org 5.1 NetBSD 5.1 (GENERIC) #0: Sat Nov 6 13:19:33 UTC 2010 builds@b6.netbsd.org:/home/builds/ab/netbsd-5-1-RELEASE/amd64/201011061943Z-obj/home/builds/ab/netbsd-5-1-RELEASE/src/sys/arch/amd64/compile/GENERIC amd64
With:
$ g++ -v
Using built-in specs.
Target: x86_64--netbsd
Configured with: /usr/src/tools/gcc/../../gnu/dist/gcc4/configure --enable-long-long --disable-multilib --enable-threads --disable-symvers --build=x86_64-unknown-netbsd4.99.72 --host=x86_64--netbsd --target=x86_64--netbsd --enable-__cxa_atexit
Thread model: posix
gcc version 4.1.3 20080704 prerelease (NetBSD nb2 20081120)
I saw:
../../src/gdb/ada-typeprint.c: In function 'void print_fixed_point_type(type*, ui_file*)':
../../src/gdb/ada-typeprint.c:366: warning: passing 'float' for argument 2 to 'DOUBLEST ada_fixed_to_float(type*, LONGEST)'
../../src/gdb/value.c: In function 'LONGEST unpack_long(type*, const gdb_byte*)':
../../src/gdb/value.c:2833: warning: converting to 'LONGEST' from 'DOUBLEST'
../../src/gdb/value.c:2838: warning: converting to 'LONGEST' from 'DOUBLEST'
gdb/ChangeLog:
2016-04-14 Pedro Alves <palves@redhat.com>
* ada-typeprint.c (print_fixed_point_type): Don't pass float as
argument to function expecting LONGEST.
* value.c (unpack_long): Add casts to LONGEST.
This test exercises the scenarios where we attempt to connect GDB to GDBserver
in standard remote mode, query the symbol file path, attempt to open said
symbol file on GDB's end and fail, causing the connection to drop abruptly.
Regression-tested on x86-64/Ubuntu.
With an unpatched GDB we should see this:
FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=: action=permission: connection to GDBserver succeeded (the program is no longer running)
FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=: action=delete: connection to GDBserver succeeded (the program is no longer running)
FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: connection to GDBserver succeeded (the program is no longer running)
FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=delete: connection to GDBserver succeeded (the program is no longer running)
A patched GDB should have full passes.
gdb/testsuite/ChangeLog:
2016-04-13 Luis Machado <lgustavo@codesourcery.com>
* gdb.server/connect-with-no-symbol-file.c: New file.
* gdb.server/connect-with-no-symbol-file.exp: New file.
When we attempt to debug a process using GDBserver in standard remote mode
without a symbol file on GDB's end, we may run into an issue where GDB cuts
the connection attempt short due to an error. The error is caused by not
being able to open a symbol file, like so:
--
(gdb) set sysroot
(gdb) tar rem :2345
Remote debugging using :2345
/proc/23769/exe: Permission denied.
(gdb) i r
The program has no registers now.
(gdb)
It should've been like this:
(gdb) set sysroot
(gdb) tar rem :2345
Remote debugging using :2345
warning: /tmp/symbol-file: Permission denied.
0xf7ddb2d0 in ?? ()
(gdb) i r
eax 0x0 0
ecx 0x0 0
edx 0x0 0
ebx 0x0 0
esp 0xffffdfa0 0xffffdfa0
ebp 0x0 0x0
esi 0x0 0
edi 0x0 0
eip 0xf7ddb2d0 0xf7ddb2d0
eflags 0x200 [ IF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb)
This is caused by a couple of function calls within exec_file_locate_attach
that can potentially throw errors.
The following patch guards both exec_file_attach and symbol_file_add_main to
prevent the errors from disrupting the connection process.
There was also a case where native GDB tripped on this problem, but it was
mostly fixed by bf74e428bc.
Regression-tested on x86-64/Ubuntu.
gdb/ChangeLog:
2016-04-13 Luis Machado <lgustavo@codesourcery.com>
* exec.c (exec_file_locate_attach): Guard a couple functions
that can throw errors.
(exception_print_same): New helper function.
This patch fixes the documentation for the zero_ext bytecode description.
It removes parts that seemed like a copy/paste from ext, since zero_ext
zeros the bits to the left.
gdb/doc/ChangeLog:
* agentexpr.texi (zero_ext): Fix zero_ext description.
This patch fixes the current comment in gdb_remote_download, which is
false (the "except if that's already where it is" part). It also
improves it, by explaining why pass TOFILE through standard_output_file,
even it is an absolute path.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_remote_download): Fix and extend comment.
gdbserver-base.exp is used as the base for both native-gdbserver.exp and
native-extended-gdbserver.exp. (Despite its name, it should really be
considered as a "local-gdbserver-base", as it's not really appropriate to
implement a remote gdbserver board.)
Currently, the _download procedure is implemented as a no-op (it returns
the source file path). Because of the SONAME change, The fast
tracepoint tests now require the executable and the IPA
(libinproctrace.so) to be located in the same directory (see [1]). When
using the native-gdbserver board, because _download returns the original
file path, the executable does not end up in the same directory as the
library, and it fails to execute.
In more general terms, with the recent changes, the testsuite now
assumes that when it does
${board}_download <source path 1> <destination path 1>
${board}_download <source path 2> <destination path 2>
where the destination paths are relative (generally just the file name),
both files will end up in the same base directory. That assumption does
not hold for the current implementation in gdbserver-base.exp.
The proper fix would be to make native-gdbserver non-remote, so that
gdb_remote_download would not call DejaGnu's remote_download (see [2]).
We could then get rid of ${board}_download in gdbserver-base.exp.
However, that will likely take some time to complete. In the mean time,
in order to make the fast tracepoint tests pass, we can simply copy the
file to the standard output directory. Basically, it just mimics what
gdb_remote_download would do if the board wasn't flagged as remote.
Note that I missed these failures originally because I had a
libinproctrace.so in /usr/local/lib. So, even though libinproctrace.so
wasn't copied to the test output directory, it did find the one in
/usr/local/lib. It would be nice to find a way to protect against this,
as it could easily happen again...
Regtested with unix, native-gdbserver and native-extended-gdbserver, and
didn't see anything notable, except the ftrace tests now passing for
native-gdbserver.
[1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=6e774b13c3b81ac2599812adf058796948ce7e95
[2] https://sourceware.org/ml/gdb-patches/2016-04/msg00112.html
gdb/testsuite/ChangeLog:
* boards/gdbserver-base.exp (${board}_download): Copy source file to
standard output directory.
This patch fixes the following failure:
FAIL: gdb.trace/trace-condition.exp: ftrace: -(21 << 1) == -42: check 10
frames were collected.
This was due to aarch64_emit_sub using the wrong order in its operands, so the
operation would end up being 42 - 0 rather than 0 - 42.
This patch also fixes the order of aarch64_emit_add for clarity.
The test case for emit_sub is fixed so that the proper order of
the operands is needed for the test to pass.
Tested on aarch64-native-extended-gdbserver.
Note: trace-condition.exp was broken a bit so I had to modify it to run
the test. A fix is coming for that in another patch.
gdb/gdbserver/ChangeLog:
* linux-aarch64-low.c (aarch64_emit_add): Switch x1 and x0.
(aarch64_emit_sub): Likewise.
gdb/testsuite/ChangeLog:
* gdb.trace/trace-condition.exp (foreach): Fix emit_sub testcase.
Reverse debugging against a remote target that does reverse debugging
itself (with the bs/bc packets) always trips on:
(gdb) target remote localhost:...
(gdb) reverse-stepi
../../gdb/target.c:602: internal-error: default_execution_direction: to_execution_direction must be implemented for reverse async
I missed adding a to_execution_direction method to remote.c in commit
3223143295 (Adds target_execution_direction to make record targets
support async mode), GDB 7.4 time. Later, GDB 7.8 switched to
target-async on by default, making the regression user-visible by
default too.
Fix is simply to add the missing to_execution_direction implementation
to target remote.
Tested by Andi Kleen against Simics.
gdb/ChangeLog:
2016-04-13 Pedro Alves <palves@redhat.com>
PR remote/19840
* remote.c (struct remote_state) <last_resume_exec_dir>: New
field.
(new_remote_state): Default last_resume_exec_dir to EXEC_FORWARD.
(remote_open_1): Reset last_resume_exec_dir to EXEC_FORWARD.
(remote_resume): Store the last execution direction.
(remote_execution_direction): New function.
(init_remote_ops): Install it as to_execution_direction target_ops
method.
On systems with a newer version of GCC the gdb.btrace/instruction_history.exp
test fails to build like this:
Running .../gdb.btrace/instruction_history.exp ...
gdb compile failed, .../gdb.btrace/instruction_history.c:
In function 'main': .../gdb.btrace/instruction_history.c:24:3: warning:
implicit declaration of function 'loop' [-Wimplicit-function-declaration]
loop ();
^
Declare loop to fix it.
testsuite/
* gdb.btrace/instruction_history.c (loop): Add declaration.
This obvious patch replaces "ond" wiht "cond" as the test prefix for
conditional tests.
gdb/testsuite/ChangeLog:
* gdb.trace/ftrace.exp (proc): Change test prefix from "ond" to "cond".
Now that we don't ever throw GDB exceptions from signal handlers [1],
we can switch back to having TRY/CATCH implemented in terms of C++
try/catch instead of sigjmp/longjmp.
[1] - https://sourceware.org/ml/gdb-patches/2016-03/msg00351.html
Tested on x86_64 Fedora 23, native and gdbserver.
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* common/common-exceptions.h (GDB_XCPT_TRY): Update comment.
[__cplusplus] (GDB_XCPT): Define as GDB_XCPT_TRY.
Now that we don't ever throw GDB exceptions from signal handlers [1],
we can switch to have TRY/CATCH implemented in terms of plain
setjmp/longjmp instead of sigsetjmp/siglongjmp.
In https://sourceware.org/ml/gdb-patches/2015-02/msg00114.html, Yichun
Zhang mentions a 11%/14%+ speedup in his GDB python scripts with a
patch that did something similar to only a specific set of TRY/CATCH
calls.
[1] - https://sourceware.org/ml/gdb-patches/2016-03/msg00351.html
Tested on x86_64 Fedora 23, native and gdbserver.
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <buf>: Now a
'jmp_buf' instead of SIGJMP_BUF.
(exceptions_state_mc_init): Change return type to 'jmp_buf'.
(throw_exception): Use longjmp instead of SIGLONGJMP.
* common/common-exceptions.h: Include <setjmp.h> instead of
"gdb_setjmp.h".
(exceptions_state_mc_init): Change return type to 'jmp_buf'.
[GDB_XCPT == GDB_XCPT_SJMP] (TRY): Use setjmp instead of
SIGSETJMP.
* cp-support.c: Include "gdb_setjmp.h".
This finally gets rid of immediate_quit (and surrounding
infrustruture), as nothing sets it anymore.
gdb_call_async_signal_handler was only necessary in order to handle
immediate_quit. We can just call mark_async_signal_handler directly
on all hosts now.
In turn, we can clean up mingw-hdep.c's gdb_select a bit, as
sigint_event / sigint_handler is no longer needed.
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* defs.h: Update comments on SIGINT handling.
(immediate_quit): Delete declaration.
* event-loop.c (call_async_signal_handler): Delete.
* event-loop.h (call_async_signal_handler): Delete declaration.
(mark_async_signal_handler): Update comments.
(gdb_call_async_signal_handler): Delete declaration.
* event-top.c (handle_sigint): Call mark_async_signal_handler
instead of gdb_call_async_signal_handler.
* exceptions.c (prepare_to_throw_exception): Remove reference to
immediate_quit.
(exception_fprintf): Remove comments about immediate_quit.
* mingw-hdep.c (sigint_event, sigint_handler): Delete.
(gdb_select): Don't wait on sigint_event.
(gdb_call_async_signal_handler): Delete.
(_initialize_mingw_hdep): Delete.
* posix-hdep.c (gdb_call_async_signal_handler): Delete.
* utils.c (immediate_quit): Delete.
remote.c is the last user of immediate_quit. It's relied on to
immediately break the initial remote connection sync up, if the user
does Ctrl-C, assuming that was because the target isn't responding.
At that stage, since the connection isn't synced yet, disconnecting is
the only safe thing to do. This commit reworks that, to not rely on
throwing from the SIGINT signal handler.
So, this commit:
- Introduces the concept of a "quit handler". This is used to
override what does the QUIT macro do when the quit flag is set.
- Makes the "struct serial" reachar / write code call QUIT in the
partial read/write loops, so the current quit handler is invoked
whenever a serial->read_prim / serial->write_prim returns EINTR.
- Makes the "struct serial" reachar / write code call
interruptible_select instead of gdb_select, so that QUITs are
detected in a race-free manner.
- Stops remote.c from setting immediate_quit during the initial
connection.
- Instead, we install a custom quit handler whenever we're calling
into the serial code. This custom quit handler knows to immediately
throw a quit when we're in the initial connection setup, and
otherwise defer handling the quit/Ctrl-C request to later, when
we're safely out of a packet command/response sequence. This also
is what is now responsible for handling "double Ctrl-C because
target connection is stuck/wedged."
- remote.c no longer installs a specialized SIGINT handlers, and
instead re-uses the quit flag. Since we want to rely on the QUIT
macro, the SIGINT handler must also set the quit. And the easiest
is just to not install custom SIGINT handler in remote.c. Let the
standard SIGINT handler do its job of setting the quit flag.
Centralizing SIGINT handlers seems like a good thing to me, anyway.
gdb/ChangeLog:
2016-04-12 Pedro Alves <palves@redhat.com>
* defs.h (quit_handler_ftype, quit_handler)
(make_cleanup_override_quit_handler, default_quit_handler): New.
(QUIT): Adjust comments.
* event-top.c (default_quit_handler): New function.
(quit_handler): New global.
(struct quit_handler_cleanup_data): New.
(restore_quit_handler, restore_quit_handler_dtor)
(make_cleanup_override_quit_handler): New.
(async_request_quit): Call QUIT.
* remote.c (struct remote_state) <got_ctrlc_during_io>: New field.
(async_sigint_remote_twice_token, async_sigint_remote_token):
Delete.
(remote_close): Update comments.
(remote_start_remote): Don't set immediate_quit. Set starting_up
earlier.
(remote_serial_quit_handler, remote_unpush_and_throw): New
functions.
(remote_open_1): Clear got_ctrlc_during_io. Set
remote_async_terminal_ours_p unconditionally.
(async_initialize_sigint_signal_handler)
(async_handle_remote_sigint, async_handle_remote_sigint_twice)
(remote_check_pending_interrupt, async_remote_interrupt)
(async_remote_interrupt_twice)
(async_cleanup_sigint_signal_handler, ofunc)
(sync_remote_interrupt, sync_remote_interrupt_twice): Delete.
(remote_terminal_inferior, remote_terminal_ours): Remove async
checks.
(remote_wait_as): Don't install a SIGINT handler in sync mode.
(readchar, remote_serial_write): Override the quit handler with
remote_serial_quit_handler.
(getpkt_or_notif_sane_1): Don't call QUIT.
(initialize_remote_ops): Don't install
remote_check_pending_interrupt.
(_initialize_remote): Don't create async_sigint_remote_token and
async_sigint_remote_twice_token.
* ser-base.c (ser_base_wait_for): Call QUIT and use
interruptible_select.
(ser_base_write): Call QUIT.
* ser-go32.c (dos_readchar, dos_write): Call QUIT.
* ser-unix.c (wait_for): Don't use VTIME. Always take the
gdb_select path, but call QUIT and interruptible_select.
* utils.c (maybe_quit): Call the current quit handler. Don't call
target_check_pending_interrupt.
(defaulted_query, prompt_for_continue): Override the quit handler
with the default quit handler.
