gdb/doc/ChangeLog:
2016-03-15 Pedro Alves <palves@redhat.com>
Andreas Arnez <arnez@linux.vnet.ibm.com>
Marcin Kościelnicki <koriakin@0x04.net>
* gdb.texinfo (Tracepoint Actions): Document possible
unreliability of '$_ret'.
When adding the $_as_string convenience function, I missed a new test
failure in default.exp. The tests lists the convenience functions, so
$_as_string should be added to the expected list.
Fixes:
+FAIL: gdb.base/default.exp: show convenience ($_caller_is = <internal function _caller_is> not found)
gdb/testsuite/ChangeLog:
* gdb.base/default.exp: Add $_as_string to the list of expected
convenience functions.
Add a new command 'maint info line-table' to display the contents of
GDB's internal line table structure. Useful when trying to understand
problems (within gdb) relating to line tables.
gdb/ChangeLog:
* symmisc.c (maintenance_info_line_tables): New function.
(maintenance_print_one_line_table): New function.
(_initialize_symmisc): Register 'maint info line-table' command.
* NEWS: Mention new command.
gdb/doc/ChangeLog:
* gdb.texinfo (Symbols): Document new 'maint info line-table'
command.
gdb/testsuite/ChangeLog:
* gdb.base/maint.exp: New tests for 'maint info line-table'.
gdb/ChangeLog:
* s390-linux-tdep.c (s390_ax_pseudo_register_collect): New function.
(s390_ax_pseudo_register_push_stack): New function.
(s390_gdbarch_init): Fill ax_pseudo_register_collect and
ax_pseudo_register_push_stack hooks.
This patch is a follow-up to "Add printf format specifier for printing
enumerator":
https://sourceware.org/ml/gdb-patches/2016-02/msg00144.html
Instead of having a solution specific to the printf command, Pedro
suggested adding a general purpose function $_as_string() that would
cover this use case and more.
So, in order to print the textual label of an enum, one can use:
(gdb) printf "Visiting node of type %s\n", $_as_string(node)
Visiting node of type NODE_INTEGER
gdb/ChangeLog:
* data-directory/Makefile.in (PYTHON_FILE_LIST): Install
gdb/function/as_string.py.
* python/lib/gdb/function/as_string.py: New file.
* NEWS: Mention the new $_as_string function.
gdb/testsuite/ChangeLog:
* gdb.python/py-as-string.exp: New file.
* gdb.python/py-as-string.c: New file.
gdb/doc/ChangeLog:
* gdb.texinfo (Convenience Functions): Document $_as_string.
These tests should have been adjusted by f303dbd60d (Fix PR
threads/19422 - show which thread caused stop), but clearly I had
missed grepping for potential-fail cases.
gdb/testsuite/ChangeLog
2016-03-09 Pedro Alves <palves@redhat.com>
* gdb.threads/attach-into-signal.exp: Adjust to "Program received
signal" -> "Thread NN received signal" output change.
* gdb.threads/ia64-sigill.exp: Likewise.
* gdb.threads/linux-dp.exp: Likewise.
* gdb.threads/manythreads.exp: Likewise.
* gdb.threads/pending-step.exp: Likewise.
* gdb.threads/print-threads.exp: Likewise.
* gdb.threads/sigstep-threads.exp: Likewise.
* gdb.threads/staticthreads.exp: Likewise.
* gdb.threads/tls.exp: Likewise.
I didn't manage to usefully split this further into smaller
independent pieces, so:
- Use "struct buffer" more.
- Split out the responsibility of composing a complete command line
from multiple input lines split with backslash
(
E.g.:
(gdb) print \
1 + \
2
$1 = 3
(gdb)
)
to a separate function. Note we don't need the separate
readline_input_state and more_to_come globals at all. They were
just obfuscating the logic.
- Factor out the tricky mostly duplicated code in
command_line_handler and command_line_input.
gdb/ChangeLog
2016-03-09 Pedro Alves <palves@redhat.com>
* event-top.c (more_to_come): Delete.
(struct readline_input_state): Delete.
(readline_input_state): Delete.
(get_command_line_buffer): New function.
(command_handler): Update comments. Don't handle NULL commands
here. Do not execute commented lines.
(command_line_append_input_line): New function.
(handle_line_of_input): New function, partly based on
command_line_handler and command_line_input.
(command_line_handler): Rewrite.
* event-top.h (command_handler): New declaration.
(command_loop): Defer command execution to command_handler.
(command_line_input): Update comments. Simplify, using struct
buffer and handle_line_of_input.
* top.h (struct buffer): New forward declaration.
(handle_line_of_input): New declaration.
There doesn't seem to be much point in trying to reuse this buffer.
Prefer simplicity instead.
(In case you're wondering whether this fixes an off-by-one: linelength
is misnamed; it's really a size including terminating null char.)
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* event-top.c (command_line_handler): Use xfree + xstrdup instead
of xrealloc + strcpy.
* main.c (captured_main): Use xstrdup instead of xmalloc plus
manual clear.
* top.c (saved_command_line): Rewrite comment.
(saved_command_line_size): Delete.
(command_line_input): Use xfree + xstrdup instead of xrealloc +
strcpy.
* top.h (saved_command_line_size): Delete declaration.
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* event-top.c: Include buffer.h.
(gdb_readline_no_editing_callback): Use struct buffer instead
of xrealloc.
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* common/buffer.h (buffer_grow_char): New function.
* top.c: Include buffer.h.
(gdb_readline_no_editing): Rename 'prompt_arg' parameter to
'prompt'. Use struct buffer instead of xrealloc.
Name this such that it's clearer that this is not a wrapper for the
real readline, but instead a replacement that provides no command line
editing features.
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* defs.h (gdb_readline): Delete declaration.
* top.c (gdb_readline): Rename to ...
(gdb_readline_no_editing): ... this, and make static.
These comments are out of date -- we no longer call gdb_readline. And
I think that mentioning the event loop is more useful here than
whatever GO32 issue had with gdb_readline, which may even no longer be
an issue.
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* utils.c (prompt_for_continue): Update comments.
The comments and existence of this global are a bit of misleading
obfuscation, since this is only ever used to print the prompt
annotation, and never changes. Just hardcode "prompt" where
necessary, as done for most other annotations.
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* event-top.c (async_annotation_suffix): Delete.
(top_level_prompt, command_line_handler): Don't use
'async_annotation_suffix' and simplify.
* event-top.h (async_annotation_suffix): Delete declaration.
(init_main): Remove reference to 'async_annotation_suffix'.
I checked, and Insight doesn't set this.
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* top.c (window_hook): Delete.
(command_loop): Remove references to window_hook.
I happened to break this locally and the testsuite didn't notice it.
Add some tests.
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* gdb.base/command-line-input.exp: New file.
gdb/gdbserver/ChangeLog:
* linux-ppc-low.c (ppc_supports_tracepoints): New function.
(struct linux_target_ops): Wire in the above.
gdb/testsuite/ChangeLog:
* gdb.trace/ftrace.exp: Set arg0exp for ppc.
* gdb.trace/mi-trace-unavailable.exp: Set pcnum for ppc.
* gdb.trace/pending.exp: Accept leading dot before function name.
* gdb.trace/trace-common.h: Add fast tracepoint dummy insn for ppc.
* lib/trace-support.exp: Set registers for ppc.
On powerpc64, "disassemble foo" doesn't work properly on object files
(it can't process the relocations in .opd section) - instead, let's
link it into an executable and load that.
Also, backtrace displays .main, not main. Accept both.
gdb/testsuite/ChangeLog:
* gdb.trace/entry-values.exp: Link ${binfile}1.o to ${binfile}1 and
use it for disassembly; accept .main in addition to main in backtrace.
tfind.exp sets a breakpoint on *gdb_recursion_test, which is the global
entry point on ppc64le, and won't be hit, since the call uses
the local entry. Fix by calling the function via a pointer in a global
variable, forcing use of the global entry.
This patch is a slightly modified hunk extracted from
https://sourceware.org/ml/gdb-patches/2015-07/msg00353.html
gdb/testsuite/ChangeLog:
2016-03-09 Wei-cheng Wang <cole945@gmail.com>
Marcin Kościelnicki <koriakin@0x04.net>
* gdb.trace/actions.c (gdb_recursion_test_fp): New typedef.
(gdb_recursion_test_ptr): New global variable.
(gdb_recursion_test): Call gdb_recursion_test_ptr instead of
gdb_recursion_test.
(gdb_c_test): Ditto.
powerpc (32-bit) loads shared libraries below the main executable, so
the PENDING location is the first one, which the current regex doesn't
match. Split it into two tests instead, one looking for the pending
tracepoint location, and the other for two installed locations.
gdb/testsuite/ChangeLog:
* gdb.trace/change-loc.exp: Don't depend on tracepoint location
ordering.
On powerpc64, foo/bar point to a function descriptor, not to function code.
Since there are no global labels pointing at the actual function code,
let's make our own.
Regression-tested on x86_64.
gdb/testsuite/ChangeLog:
* gdb.trace/unavailable-dwarf-piece.c (foo): Add foo_start_lbl label.
(bar): Add bar_start_lbl label.
* gdb.trace/unavailable-dwarf-piece.exp: Use foo/bar_start_lbl instead
of foo/bar for emitting DWARF and tracing.
Previously, backchain was read as a signed quantity, resulting in
addresses like 0xfffffffffffeded0 instead of 0xfffeded0 returned by
unwinder on 32-bit powerpc. While normally such addresses are masked
off, this causes problems for tracepoints, since 0xfffffffffffeded0
is considered unavailable.
Fixes a test failure in gdb.trace/entry-values.exp.
gdb/ChangeLog:
* corefile.c (safe_read_memory_unsigned_integer): New function.
* gdbcore.h (safe_read_memory_unsigned_integer): New prototype.
* rs6000-tdep.c (rs6000_frame_cache): Read backchain as unsigned.
gdb/ChangeLog:
* rs6000-tdep.c: Add "ax.h" and "ax-gdb.h" includes.
(rs6000_gen_return_address): New function.
(rs6000_gdbarch_init): Wire in the above.
Functions compiled with the gcc option `-mhotpatch' may start with a
branch-never BRCL instruction as a 6-byte NOP. And functions compiled
with `-mstack-size' contain a BRC instruction in their prologue that is
actually a conditional trap. Both of these special jumps cause the
prologue parser to stop and yield bad unwinding results.
This change makes the prologue analyzer recognize such special jumps and
ignore them.
gdb/ChangeLog:
* s390-linux-tdep.c (s390_analyze_prologue): Ignore BRC and BRCL
instructions that do nothing or are conditional traps.
When determining the frame ID of an inline frame, GDB currently asserts
that a valid ID of the underlying real frame is found, and that it does
not match outer_frame_id. From inline_frame_this_id():
/* For now, require we don't match outer_frame_id either (see
comment above). */
gdb_assert (!frame_id_eq (*this_id, outer_frame_id));
However, this assertion may fail when the real frame's unwinder can not
determine the frame ID. This happened on an s390x target with a binary
that lacked call frame information and also confused the prologue
analyzer, because then s390_frame_this_id() left the frame ID at its
default.
To fix this, this change enhances s390_frame_this_id such that an
unavailable-stack frame ID is built if no frame base can be determined
but the function address is available.
gdb/ChangeLog:
* s390-linux-tdep.c (s390_prologue_frame_unwind_cache): Store
frame func's PC in info->func before any other failure can occur.
(s390_frame_this_id): Use frame_id_build_unavailable_stack if
info->func has been filled out.
It's not possible today to select some of the osabis by name.
Specifically, those that have spaces in their names and then the first
word is ambiguous...
For example:
(gdb) set osabi <TAB>
[...]
FreeBSD ELF
FreeBSD a.out
[...]
(gdb) set osabi FreeBSD ELF
Ambiguous item "FreeBSD ELF".
In reality, because "set osabi" is an enum command, that was
equivalent to trying "set osabi FreeBSD", which is then obviously
ambiguous, because of "FreeBSD ELF" and "FreeBSD a.out".
Also, even if the first word is not ambiguous, we actually ignore
whatever comes after the first word:
(gdb) set osabi GNU/Linux
(gdb) show osabi
The current OS ABI is "GNU/Linux".
The default OS ABI is "GNU/Linux".
(gdb) set osabi Windows SomeNonsense
^^^^^^^^^^^^
(gdb) show osabi
The current OS ABI is "Windows CE".
The default OS ABI is "GNU/Linux".
(gdb)
Fix this by avoiding spaces in osabi names.
We could instead make "set osabi" have a custom set hook, or
alternatively make the enum set hook (in cli-setshow.c) handle values
with spaces, but OTOH, I have a feeling that could cause trouble.
E.g., in cases where we might want to write more than one enum value
in the same line. We could support quoting as workaround, but, not
sure we want that. "No spaces" seems like a simpler rule.
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* osabi.c (gdb_osabi_names): Avoid spaces in osabi names.
Even though "set architecture" presents fr300 as option:
(gdb) set architecture fr<TAB>
fr300 fr400 fr450 fr500 fr550 frv
Actually selecting fr300 doesn't work:
(gdb) set architecture fr300
Architecture `fr300' not recognized.
The target architecture is set automatically (currently i386)
(gdb)
This just looks like an obvious oversight. Looking around gcc and
binutils sources, FR300 is basically a FR500 specialized for DSP and
low power.
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* frv-tdep.c (frv_gdbarch_init): Handle bfd_mach_fr300.
This fixes:
$ ./gdb -q -ex "set endian big" -ex "set architecture cris"
The target is assumed to be big endian
.../src/gdb/cris-tdep.c:4051: internal-error: cris_gdbarch_init: big endian byte order in info
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
The "set cris-version" command can likewise cause internal errors.
The gdbarch init routine should be returning 0 to reject the
architecture instead of internal erroring on user input.
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* cris-tdep.c (cris_gdbarch_init): Return 0 if the info's byte
order is BFD_ENDIAN_BIG or if the cris version is unsupported.
Running the testsuite with a gdb configured with --enable-libmcheck
reveals a problem:
(gdb) ptype 3 * 2.0
type = <12-byte float>
memory clobbered past end of allocated block
ERROR: Process no longer exists
UNRESOLVED: gdb.ada/ptype_arith_binop.exp: ptype 3 * 2.0
(gdb) PASS: gdb.dlang/expression.exp: ptype 0x1.FFFFFFFFFFFFFp1023
ptype 0x1p-52L
type = real
memory clobbered past end of allocated block
ERROR: Process no longer exists
UNRESOLVED: gdb.dlang/expression.exp: ptype 0x1p-52L
Even though this shows up with Ada and D, it's easy to reproduce in C
too. We just need to print a long double, when the current arch is
32-bit, which is the default when gdb starts up:
$ ./gdb -q -ex "ptype 1.0L"
type = long double
memory clobbered past end of allocated block
Aborted (core dumped)
Valgrind shows:
==22159== Invalid write of size 8
==22159== at 0x8464A9: floatformat_from_doublest (doublest.c:756)
==22159== by 0x846822: store_typed_floating (doublest.c:867)
==22159== by 0x6A7959: value_from_double (value.c:3662)
==22159== by 0x6A9F2D: evaluate_subexp_standard (eval.c:745)
==22159== by 0x7F31AF: evaluate_subexp_c (c-lang.c:716)
==22159== by 0x6A8986: evaluate_subexp (eval.c:79)
==22159== by 0x6A8BA3: evaluate_type (eval.c:174)
==22159== by 0x817CCF: whatis_exp (typeprint.c:456)
==22159== by 0x817EAA: ptype_command (typeprint.c:508)
==22159== by 0x5F267B: do_cfunc (cli-decode.c:105)
==22159== by 0x5F5618: cmd_func (cli-decode.c:1885)
==22159== by 0x83622A: execute_command (top.c:475)
==22159== Address 0x8c6cb28 is 8 bytes inside a block of size 12 alloc'd
==22159== at 0x4C2AA98: calloc (vg_replace_malloc.c:711)
==22159== by 0x87384A: xcalloc (common-utils.c:83)
==22159== by 0x873889: xzalloc (common-utils.c:93)
==22159== by 0x6A34CB: allocate_value_contents (value.c:1036)
==22159== by 0x6A3501: allocate_value (value.c:1047)
==22159== by 0x6A790A: value_from_double (value.c:3656)
==22159== by 0x6A9F2D: evaluate_subexp_standard (eval.c:745)
==22159== by 0x7F31AF: evaluate_subexp_c (c-lang.c:716)
==22159== by 0x6A8986: evaluate_subexp (eval.c:79)
==22159== by 0x6A8BA3: evaluate_type (eval.c:174)
==22159== by 0x817CCF: whatis_exp (typeprint.c:456)
==22159== by 0x817EAA: ptype_command (typeprint.c:508)
==22159==
type = long double
(gdb)
Even if the target and host floating-point formats match, the length
of the types might still be different. On x86, long double is the
80-bit extended precision type on both 32-bit and 64-bit ABIs, but by
default it is stored as 12 bytes on 32-bit, and 16 bytes on 64-bit,
for alignment reasons. Several places in doublest.c already consider
this, but floatformat_to_doublest and floatformat_from_doublest miss
it. E.g., convert_typed_floating and store_typed_floating,
Tested on x86-64 Fedora 23 with --enable-libmcheck, where it fixes the
crashed above.
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* doublest.c: Extend comments.
(floatformat_to_doublest, floatformat_from_doublest): Copy the
floatformat's total size, not the host type's size.
This would have caught the HP/PA bug fixed in the previous patch:
.../src/gdb/gdbtypes.c:4690: internal-error: arch_float_type: Assertion `len >= floatformat_totalsize_bytes (floatformats[0])' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
Tested on x86-64 Fedora 23, --enable-targets=all.
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* doublest.c (floatformat_totalsize_bytes): New function.
(floatformat_from_type): Assert that the type's length is at least
as long as the floatformat's totalsize.
* doublest.h (floatformat_totalsize_bytes): New declaration.
* gdbtypes.c (arch_float_type): Assert that the type's length is
at least as long as the floatformat's totalsize.
This:
$ ./gdb -ex "set architecture hppa1.0" -ex "set osabi GNU/Linux" -ex "ptype 1.0L"
Shows that HPPA/Linux support for long doubles is broken. It causes
GDB to access memory out of bounds. With Valgrind, we see:
The target architecture is assumed to be hppa1.0
==4371== Invalid write of size 8
==4371== at 0x4C2F21F: memset (vg_replace_strmem.c:1224)
==4371== by 0x8451C4: convert_doublest_to_floatformat (doublest.c:362)
==4371== by 0x845F86: floatformat_from_doublest (doublest.c:769)
==4371== by 0x84628E: store_typed_floating (doublest.c:873)
==4371== by 0x6A7C3D: value_from_double (value.c:3662)
==4371== by 0x6AA211: evaluate_subexp_standard (eval.c:745)
==4371== by 0x7F306D: evaluate_subexp_c (c-lang.c:716)
==4371== by 0x6A8C6A: evaluate_subexp (eval.c:79)
==4371== by 0x6A8E87: evaluate_type (eval.c:174)
==4371== by 0x817B8D: whatis_exp (typeprint.c:456)
==4371== by 0x817D68: ptype_command (typeprint.c:508)
==4371== by 0x5F2977: do_cfunc (cli-decode.c:105)
==4371== Address 0x8998d18 is 0 bytes after a block of size 8 alloc'd
==4371== at 0x4C2AA98: calloc (vg_replace_malloc.c:711)
==4371== by 0x8732B6: xcalloc (common-utils.c:83)
==4371== by 0x8732F5: xzalloc (common-utils.c:93)
==4371== by 0x6A37AF: allocate_value_contents (value.c:1036)
==4371== by 0x6A37E5: allocate_value (value.c:1047)
==4371== by 0x6A7BEE: value_from_double (value.c:3656)
==4371== by 0x6AA211: evaluate_subexp_standard (eval.c:745)
==4371== by 0x7F306D: evaluate_subexp_c (c-lang.c:716)
==4371== by 0x6A8C6A: evaluate_subexp (eval.c:79)
==4371== by 0x6A8E87: evaluate_type (eval.c:174)
==4371== by 0x817B8D: whatis_exp (typeprint.c:456)
==4371== by 0x817D68: ptype_command (typeprint.c:508)
The trouble is that hppa_linux_init_abi overrides the default
long_double_bit set by the generic hppa-tdep.c:
set_gdbarch_long_double_bit (gdbarch, 128);
set_gdbarch_long_double_format (gdbarch, floatformats_ia64_quad);
with:
/* On hppa-linux, currently, sizeof(long double) == 8. There has been
some discussions to support 128-bit long double, but it requires some
more work in gcc and glibc first. */
set_gdbarch_long_double_bit (gdbarch, 64);
which misses overriding the long_double_format, so we end with a weird
combination of:
set_gdbarch_long_double_bit (gdbarch, 64);
set_gdbarch_long_double_format (gdbarch, floatformats_ia64_quad);
Weird because floatformats_ia64_quad's totalsize is longer than 64-bits.
The floatformat conversion routines use the struct floatformat's
totalsize (in bits) to know how much to copy/convert, thus the buffer
overruns.
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* hppa-linux-tdep.c (hppa_linux_init_abi): Set the long double
format to floatformats_ieee_double.
Fix this GDB crash:
$ gdb -ex "set architecture mips:10000"
Segmentation fault (core dumped)
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x0000000000495b1b in mips_gdbarch_init (info=..., arches=0x0) at /home/pedro/gdb/mygit/cxx-convertion/src/gdb/mips-tdep.c:8436
8436 if (bfd_get_flavour (info.abfd) == bfd_target_elf_flavour
(top-gdb) bt
#0 0x0000000000495b1b in mips_gdbarch_init (info=..., arches=0x0) at .../src/gdb/mips-tdep.c:8436
#1 0x00000000007348a6 in gdbarch_find_by_info (info=...) at .../src/gdb/gdbarch.c:5155
#2 0x000000000073563c in gdbarch_update_p (info=...) at .../src/gdb/arch-utils.c:522
#3 0x0000000000735585 in set_architecture (ignore_args=0x0, from_tty=1, c=0x26bc870) at .../src/gdb/arch-utils.c:496
#4 0x00000000005f29fd in do_sfunc (c=0x26bc870, args=0x0, from_tty=1) at .../src/gdb/cli/cli-decode.c:121
#5 0x00000000005fd3f3 in do_set_command (arg=0x7fffffffdcdd "mips:10000", from_tty=1, c=0x26bc870) at .../src/gdb/cli/cli-setshow.c:455
#6 0x0000000000836157 in execute_command (p=0x7fffffffdcdd "mips:10000", from_tty=1) at .../src/gdb/top.c:460
#7 0x000000000071abfb in catch_command_errors (command=0x835f6b <execute_command>, arg=0x7fffffffdccc "set architecture mips:10000", from_tty=1)
at .../src/gdb/main.c:368
#8 0x000000000071bf4f in captured_main (data=0x7fffffffd750) at .../src/gdb/main.c:1132
#9 0x0000000000716737 in catch_errors (func=0x71af44 <captured_main>, func_args=0x7fffffffd750, errstring=0x106b9a1 "", mask=RETURN_MASK_ALL)
at .../src/gdb/exceptions.c:240
#10 0x000000000071bfe6 in gdb_main (args=0x7fffffffd750) at .../src/gdb/main.c:1164
#11 0x000000000040a6ad in main (argc=4, argv=0x7fffffffd858) at .../src/gdb/gdb.c:32
(top-gdb)
We already check whether info.abfd is NULL before all other
bfd_get_flavour calls in the same function. Just this one case was
missing.
(This was exposed by a WIP test that tries all "set architecture ARCH"
values.)
gdb/ChangeLog:
2016-03-07 Pedro Alves <palves@redhat.com>
* mips-tdep.c (mips_gdbarch_init): Check whether info.abfd is NULL
before calling bfd_get_flavour.
I forgot to do it in my previous commit. This is necessary because we
execute the script directly on gdb/testsuite/Makefile.in.
gdb/testsuite/ChangeLog:
2016-03-06 Sergio Durigan Junior <sergiodj@redhat.com>
* analyze-racy-logs.py: Set executable bit.
This is an initial attempt to introduce some mechanisms to identify
racy testcases present in our testsuite. As can be seen in previous
discussions, racy tests are really bothersome and cause our BuildBot
to pollute the gdb-testers mailing list with hundreds of
false-positives messages every month. Hopefully, identifying these
racy tests in advance (and automatically) will contribute to the
reduction of noise traffic to gdb-testers, maybe to the point where we
will be able to send the failure messages directly to the authors of
the commits.
I spent some time trying to decide the best way to tackle this
problem, and decided that there is no silver bullet. Racy tests are
tricky and it is difficult to catch them, so the best solution I could
find (for now?) is to run our testsuite a number of times in a row,
and then compare the results (i.e., the gdb.sum files generated during
each run). The more times you run the tests, the more racy tests you
are likely to detect (at the expense of waiting longer and longer).
You can also run the tests in parallel, which makes things faster (and
contribute to catching more racy tests, because your machine will have
less resources for each test and some of them are likely to fail when
this happens). I did some tests in my machine (8-core i7, 16GB RAM),
and running the whole GDB testsuite 5 times using -j6 took 23 minutes.
Not bad.
In order to run the racy test machinery, you need to specify the
RACY_ITER environment variable. You will assign a number to this
variable, which represents the number of times you want to run the
tests. So, for example, if you want to run the whole testsuite 3
times in parallel (using 2 cores), you will do:
make check RACY_ITER=3 -j2
It is also possible to use the TESTS variable and specify which tests
you want to run:
make check TEST='gdb.base/default.exp' RACY_ITER=3 -j2
And so on. The output files will be put at the directory
gdb/testsuite/racy_outputs/.
After make invokes the necessary rules to run the tests, it finally
runs a Python script that will analyze the resulting gdb.sum files.
This Python script will read each file, and construct a series of sets
based on the results of the tests (one set for FAIL's, one for
PASS'es, one for KFAIL's, etc.). It will then do some set operations
and come up with a list of unique, sorted testcases that are racy.
The algorithm behind this is:
for state in PASS, FAIL, XFAIL, XPASS...; do
if a test's state in every sumfile is $state; then
it is not racy
else
it is racy
(The algorithm is actually a bit more complex than that, because it
takes into account other things in order to decide whether the test
should be ignored or not).
IOW, a test must have the same state in every sumfile.
After processing everything, the script prints the racy tests it could
identify on stdout. I am redirecting this to a file named racy.sum.
Something else that I wasn't sure how to deal with was non-unique
messages in our testsuite. I decided to do the same thing I do in our
BuildBot: include a unique identifier in the end of message, like:
gdb.base/xyz.exp: non-unique message
gdb.base/xyz.exp: non-unique message <<2>>
This means that you will have to be careful about them when you use
the racy.sum file.
I ran the script several times here, and it did a good job catching
some well-known racy tests. Overall, I am satisfied with this
approach and I think it will be helpful to have it upstream'ed. I
also intend to extend our BuildBot and create new, specialized
builders that will be responsible for detecting the racy tests every X
number of days.
2016-03-05 Sergio Durigan Junior <sergiodj@redhat.com>
* Makefile.in (DEFAULT_RACY_ITER): New variable.
(CHECK_TARGET_TMP): Likewise.
(check-single-racy): New rule.
(check-parallel-racy): Likewise.
(TEST_TARGETS): Adjust rule to account for RACY_ITER.
(do-check-parallel-racy): New rule.
(check-racy/%.exp): Likewise.
* README (Racy testcases): New section.
* analyze-racy-logs.py: New file.
When calling function with argument of size more than 8 bytes fails with
an error "That operation is not available on integers of more than 8 bytes.".
avr-gdb considers only 8 bytes (sizeof(long long)) in case of passing the
argument in registers. When the argument is of size more than 8 byte
then the utility function to extract bytes failed with the above error.
gdb/
* avr-tdep.c (AVR_LAST_ARG_REGNUM): Define.
(avr_push_dummy_call): Correct last needed argument register.
Write MSB of argument into register and subsequent bytes into
other registers in decreasing order.
ARM process record gets the wrong register number for VMOV (from core
register to single-precision register). That is, we should record
the D register rather than the S pseudo register. The patch also
removes the condition "bit (arm_insn_r->arm_insn, 20)" check, which
has been checked above.
It fixes the following internal error,
(gdb) PASS: gdb.reverse/finish-precsave.exp: BP at end of main
continue^M
Continuing.^M
../../binutils-gdb/gdb/regcache.c:649: internal-error: regcache_raw_read: Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed.^M
A problem internal to GDB has been detected,FAIL: gdb.reverse/finish-precsave.exp: run to end of main (GDB internal error)
gdb:
2016-03-04 Yao Qi <yao.qi@linaro.org>
* arm-tdep.c (arm_record_vdata_transfer_insn): Simplify the
condition check. Record the right D register number.
This patch removes the printing "Process record does not support",
and do the print by calling arm_record_unsupported_insn in the
caller. Also, call arm_record_extension_space only when condition
is 0xf.
gdb:
2016-03-04 Yao Qi <yao.qi@linaro.org>
* arm-tdep.c (arm_record_extension_space): Remove code
printing "Process record does not support".
(arm_record_data_proc_misc_ld_str): Likewise.
(decode_insn): Call arm_record_extension_space if condition
is 0xf. Call arm_record_unsupported_insn if ret isn't
ARM_RECORD_SUCCESS. Use 'ret' instead of 'insn_id' to hold
the value of thumb2_record_decode_insn_handler.
I found that odd that passing no arguments to feature_to_c.sh produces
this:
$ ./feature_to_c.sh
./feature_to_c.sh: 23: shift: can't shift that many
but passing one argument shows the help:
$ ./feature_to_c.sh hello
Usage: ./feature_to_c.sh OUTPUTFILE INPUTFILE...
This patch changes the script to show the help in both cases.
gdb/ChangeLog:
* features/feature_to_c.sh: Print the help when passing no
argument.
I happen to see that comments to start_step_over isn't in sync with
code, so this patch is to update the comments.
gdb/gdbserver:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* linux-low.c: Update comments to start_step_over.
This patch adds a new test for stepping over clone syscall.
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/step-over-syscall.exp (step_over_syscall): Kfail.
Invoke step_over_syscall "clone" and break_cond_on_syscall
"clone".
* gdb.base/step-over-clone.c: New file.
disp-step-syscall.exp is extended for stepping over syscall instruction
in different cases, with or without displaced stepping, and stepping
over by GDBserver.
This patch rename disp-step-syscall.exp to step-over-syscall.exp to
reflect this.
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-fork.c: Rename to ...
* gdb.base/step-over-fork.c: ... it. New file.
* gdb.base/disp-step-vfork.c: Rename to ...
* gdb.base/step-over-vfork.c: ... it. New file.
* gdb.base/disp-step-syscall.exp: Rename to ...
* gdb.base/step-over-syscall.exp: ... it. New file.
(disp_step_cross_syscall): Rename to ...
(step_over_syscall): ... it.
We can also extend disp-step-syscall.exp to test GDBserver step over
breakpoint on syscall instruction. That is, we set a breakpoint
with a false condition on syscall instruction, so that GDBserver will
step over it.
This test triggers a GDBserver internal error, which can be fixed by
this series.
(gdb) PASS: gdb.base/disp-step-syscall.exp: fork: break cond on target: break on syscall insns
continue^M
Continuing.^M
Remote connection closed^M
(gdb) FAIL: gdb.base/disp-step-syscall.exp: fork: break cond on target: continue to fork again
In GDBserver, there is an internal error,
/home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/linux-low.c:1922: A problem internal to GDBserver has been detected.
unsuspend LWP 25554, suspended=-1
the simplified reproducer is like,
$ ./gdb ./testsuite/outputs/gdb.base/disp-step-syscall/disp-step-fork
(gdb) b main
(gdb) c
(gdb) disassemble fork // in order to find the address of insn 'syscall'
....
0x00007ffff7ad6023 <+179>: syscall
(gdb) b *0x00007ffff7ad6023 if main == 0
(gdb) c
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-syscall.exp (break_cond_on_syscall): New.
If target supports condition evaluation on target, invoke
break_cond_on_syscall for fork and vfork.
disp-step-syscall.exp was added to test displaced stepping over syscall
instructions, in which we set breakpoint on syscall instruction, and
step over it. In fact, we can extend the test to non-displaced-stepping
case. This patch wraps the test with displaced stepping on and off.
Note that the indentation and format isn't adjusted here to make this
patch easy to read. The following patch will fix the format separately.
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-syscall.exp: Don't invoke
support_displaced_stepping.
(disp_step_cross_syscall): Test with displaced stepping off and
on if supported.
This patch moves some code out of disp_step_cross_syscall to a new proc
check_pc_after_cross_syscall and setup. Procedure setup is to start a
fresh GDB and compute the syscall instruction address.
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-syscall.exp (check_pc_after_cross_syscall): New
proc.
(setup): New proc.
(disp_step_cross_syscall): Move code to check_pc_after_cross_syscall
and setup.
I see the following GDBserver internal error in two cases,
gdb/gdbserver/linux-low.c:1922: A problem internal to GDBserver has been detected.
unsuspend LWP 17200, suspended=-1
1. step over a breakpoint on fork/vfork syscall instruction,
2. step over a breakpoint on clone syscall instruction and child
threads hits a breakpoint,
the stack backtrace is
#0 internal_error (file=file@entry=0x44c4c0 "gdb/gdbserver/linux-low.c", line=line@entry=1922,
fmt=fmt@entry=0x44c7d0 "unsuspend LWP %ld, suspended=%d\n") at gdb/gdbserver/../common/errors.c:51
#1 0x0000000000424014 in lwp_suspended_decr (lwp=<optimised out>, lwp=<optimised out>) at gdb/gdbserver/linux-low.c:1922
#2 0x000000000042403a in unsuspend_one_lwp (entry=<optimised out>, except=0x66e8c0) at gdb/gdbserver/linux-low.c:2885
#3 0x0000000000405f45 in find_inferior (list=<optimised out>, func=func@entry=0x424020 <unsuspend_one_lwp>, arg=arg@entry=0x66e8c0)
at gdb/gdbserver/inferiors.c:243
#4 0x00000000004297de in unsuspend_all_lwps (except=0x66e8c0) at gdb/gdbserver/linux-low.c:2895
#5 linux_wait_1 (ptid=..., ourstatus=ourstatus@entry=0x665ec0 <last_status>, target_options=target_options@entry=0)
at gdb/gdbserver/linux-low.c:3632
#6 0x000000000042a764 in linux_wait (ptid=..., ourstatus=0x665ec0 <last_status>, target_options=0)
at gdb/gdbserver/linux-low.c:3770
#7 0x0000000000411163 in mywait (ptid=..., ourstatus=ourstatus@entry=0x665ec0 <last_status>, options=options@entry=0, connected_wait=connected_wait@entry=1)
at gdb/gdbserver/target.c:214
#8 0x000000000040b1f2 in resume (actions=0x66f800, num_actions=1) at gdb/gdbserver/server.c:2757
#9 0x000000000040f660 in handle_v_cont (own_buf=0x66a630 "vCont;c:p45e9.-1") at gdb/gdbserver/server.c:2719
when GDBserver steps over a thread, other threads have been suspended,
the "stepping" thread may create new thread, but GDBserver doesn't set
it suspend count to 1. When GDBserver unsuspend threads, the child's
suspend count goes to -1, and the assert is triggered. In fact, GDBserver
has already taken care of suspend count of new thread when GDBserver is
suspending all threads except the one GDBserver wants to step over by
https://sourceware.org/ml/gdb-patches/2015-07/msg00946.html
+ /* If we're suspending all threads, leave this one suspended
+ too. */
+ if (stopping_threads == STOPPING_AND_SUSPENDING_THREADS)
+ {
+ if (debug_threads)
+ debug_printf ("HEW: leaving child suspended\n");
+ child_lwp->suspended = 1;
+ }
but that is not enough, because new thread is still can be spawned in
the thread which is being stepped over. This patch extends the
condition that GDBserver set child's suspend count to one if it is
suspending threads or stepping over the thread.
gdb/gdbserver:
2016-03-03 Yao Qi <yao.qi@linaro.org>
PR server/19736
* linux-low.c (handle_extended_wait): Set child suspended
if event_lwp->bp_reinsert isn't zero.
Replace the code which is exactly what enqueue_pending_signal does.
gdb/gdbserver:
2016-03-02 Yao Qi <yao.qi@linaro.org>
* linux-low.c (linux_resume_one_lwp_throw): Replace code with
enqueue_pending_signal.
Fixes rather embarassing gdb.trace regressions.
gdb/gdbserver/ChangeLog:
* tracepoint.c (cmd_qtstart): Only set ipa_tdesc_idx if agent
is actually loaded.
Printing and resolving of dynamic array's causes sporadic timeout issues on loaded systems.
2016-03-02 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/testsuite/Changelog:
* gdb.fortran/vla-history.exp: Lookup array elements and printing exceeds timeout.
Adding a dummy assignment as a new breakpoint anchor because
breakpoint on return statement doesn't work for GCC 5.x.
2016-03-02 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/testsuite/Changelog:
* gdb.cp/vla-cxx.cc: Insert dummy assignment as anchor for an breakpoint.
Nullify pointers to avoid an undefined association status.
2016-03-02 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/testsuite/Changelog:
* gdb.mi/vla.f90: Nullify pointer after declaration.
Add new maintainer to Write After Approval.
2016-03-02 Bernhard Heckel <bernhard.heckel@intel.com>
* MAINTAINERS (Write After Approval): Add Bernhard Heckel.
Fixes, on F23:
.../src/gdb/testsuite/gdb.trace/ftrace-lock.c: In function 'gdb_agent_gdb_collect':
.../src/gdb/testsuite/gdb.trace/ftrace-lock.c:50:3: warning: implicit declaration of function 'sleep' [-Wimplicit-function-declaration]
sleep (1);
^
gdb/testsuite/ChangeLog:
2016-03-01 Pedro Alves <palves@redhat.com>
* gdb.trace/ftrace-lock.c: Include <unistd.h>.
This testcase currently fails to compile on Fedora 23:
.../src/gdb/testsuite/gdb.threads/watchpoint-fork-mt.c: In function 'start':
.../src/gdb/testsuite/gdb.threads/watchpoint-fork-mt.c:70:11: warning: implicit declaration of function 'pthread_yield' [-Wimplicit-function-declaration]
i = pthread_yield ();
^
.../src/gdb/testsuite/gdb.threads/watchpoint-fork-child.c: In function 'forkoff':
.../src/gdb/testsuite/gdb.threads/watchpoint-fork-child.c:114:8: warning: implicit declaration of function 'pthread_yield' [-Wimplicit-function-declaratio
n]
i = pthread_yield ();
^
/tmp/ccUkNIsI.o: In function `start':
.../src/gdb/testsuite/gdb.threads/watchpoint-fork-mt.c:70: undefined reference to `pthread_yield'
(...)
collect2: error: ld returned 1 exit status
UNSUPPORTED: gdb.threads/watchpoint-fork.exp: child: multithreaded: Couldn't compile watchpoint-fork-child.c: unrecognized error
UNTESTED: gdb.threads/watchpoint-fork.exp: child: multithreaded: watchpoint-fork.exp
testcase .../src/gdb/testsuite/gdb.threads/watchpoint-fork.exp completed i
The glibc manual says, on _GNU_SOURCE:
"You should define these macros by using ‘#define’ preprocessor
directives at the top of your source code files. These directives must
come before any #include of a system header file."
I instead put it in the header all the .c files of the testcase must
include anyway.
gdb/testsuite/ChangeLog:
2016-03-01 Pedro Alves <palves@redhat.com>
* gdb.threads/watchpoint-fork-child.c: Include "watchpoint-fork.h"
before anything else.
* gdb.threads/watchpoint-fork-mt.c: Likewise. Don't define
_GNU_SOURCE here.
* gdb.threads/watchpoint-fork-st.c: Include "watchpoint-fork.h"
before anything else.
* gdb.threads/watchpoint-fork.h: Define _GNU_SOURCE.
This patch fixes the following error,
ERROR: (/scratch/yao/gdb/build-git/arm-linux-gnueabihf/gdb/testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step) No such file or directory
FAIL: gdb.arch/arm-disp-step.exp: Can't run to main
gdb/testsuite:
2016-03-01 Yao Qi <yao.qi@linaro.org>
* gdb.arch/arm-disp-step.exp: Use standard_testfile and
prepare_for_testing.
When we compile gdb.arch/arm-neon.c with options that don't enable NEON,
there are many error/warnings emitted into gdb.sum, which is annoying.
This patch fixes it by passing quiet to prepare_for_testing.
gdb/testsuite:
2016-03-01 Yao Qi <yao.qi@linaro.org>
* gdb.arch/arm-neon.exp: Pass quiet to prepare_for_testing.
Since test artifacts are always organized in a directory hierarchy, the
s390-tdbregs test case is not executed correctly any more. This is
because it uses an obsolete way of constructing the executable's path.
This change invokes prepare_for_testing instead.
gdb/testsuite/ChangeLog:
* gdb.arch/s390-tdbregs.exp: Use prepare_for_testing instead of
manually constructing the output path.
This fixes a GDB internal error that may occur when the inferior has no
valid stack pointer in r15.
gdb/testsuite/ChangeLog:
* gdb.arch/s390-stackless.S: New.
* gdb.arch/s390-stackless.exp: New.
gdb/ChangeLog:
* s390-linux-tdep.c (s390_backchain_frame_unwind_cache): Avoid
exception when attempting to access the inferior's backchain.
The last patch supports several syscalls in linux-record.c, so now
GDB aarch64-linux backend can return these canonicalized syscall numbers
per aarch64 syscall number.
This patch fixes the following fails,
Process record and replay target doesn't support syscall number 59^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0x00000020000eab28 in pipe () from /lib/aarch64-linux-gnu/libc.so.6^M
(gdb) FAIL: gdb.reverse/pipe-reverse.exp: continue to breakpoint: marker2
Process record and replay target doesn't support syscall number 59^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0x00000020000eab28 in pipe () from /lib/aarch64-linux-gnu/libc.so.6^M
(gdb) FAIL: gdb.reverse/readv-reverse.exp: continue to breakpoint: marker2
gdb:
2016-02-29 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-tdep.c (aarch64_canonicalize_syscall): Support
eventfd2, eventfd2, dup3, inotify_init1, fallocate and pipe2.
Return gdb_sys_epoll_create1 instead of gdb_sys_epoll_create
for aarch64_sys_epoll_create1.
Given two or more modules that import each other's scope, the current symbol
lookup routines would go round in circles looking through each import from
each module, possibly checking the same module twice or more until all possible
paths are marked as "searched".
Given enough modules, this causes an exponential slowdown in time taken to find
symbols that do exist, and infinite recursion when they don't.
gdb/ChangeLog:
* d-namespace.c (d_lookup_symbol_imports): Avoid recursive lookups from
cyclic imports.
gdb/testsuite/ChangeLog:
* gdb.dlang/circular.c: New file.
* gdb.dlang/circular.exp: New file.
This is an obvious patch to fix the following build error seen with
--enable-build-with-cxx:
../../src/gdb/rs6000-tdep.c: In function ‘rs6000_frame_cache* rs6000_frame_cache(frame_info*, void**)’:
../../src/gdb/rs6000-tdep.c:3242:15: error: invalid conversion from ‘void*’ to ‘rs6000_frame_cache*’ [-fpermissive]
return (*this_cache);
~^~~~~~~~~~~~
gdb/ChangeLog
* rs6000-tdep.c (rs6000_frame_cache): Explicitly cast return result
to avoid invalid conversion from void *.
This patch fixes various bugs in arm_record_exreg_ld_st_insn, and use
gdb.reverse/insn-reverse.c to test more arm instructions.
- Set flag SINGLE_REG correctly. In the arch reference manual,
SING_REG is true when the bit 8 of instruction is zero.
- Record the right D registers for instructions changing S registers.
- Fix the order of length and address in record_buf_mem array.
- Shift the offset by 2 instead of by 24.
This patch also fixes one internal error,
(gdb) PASS: gdb.reverse/finish-precsave.exp: BP at end of main
continue^M
Continuing.^M
../../binutils-gdb/gdb/utils.c:1072: internal-error: virtual memory exhausted.^M
A problem internal to GDB has been detected,FAIL: gdb.reverse/finish-precsave.exp: run to end of main (GDB internal error)
gdb:
2016-02-26 Yao Qi <yao.qi@linaro.org>
* arm-tdep.c (arm_record_exreg_ld_st_insn): Set 'single_reg'
per bit 8. Check bit 20 instead of bit 4 for VMOV
instruction. Record D registers for instructions changing
S registers. Change of the order of length and address
in record_buf_mem array.
gdb/testsuite:
2016-02-26 Yao Qi <yao.qi@linaro.org>
* gdb.reverse/insn-reverse.c [__arm__] (ext_reg_load): New.
[__arm__] (ext_reg_mov, ext_reg_push_pop): New.
(testcases): Update.
When GDB decodes these thumb special data instructions, such as 'mov sp, r7'
the Rd is got incorrectly. According to the arch reference manual, the Rd
is DN:Rdn, in which DN is bit 7 and Rdn is bits 0 to 2. This patch fixes it.
gdb:
2016-02-26 Yao Qi <yao.qi@linaro.org>
* arm-tdep.c (thumb_record_ld_st_reg_offset): Fix the register
number of Rd.
gdb/testsuite:
2016-02-26 Yao Qi <yao.qi@linaro.org>
* gdb.reverse/aarch64.c: Rename to ...
* gdb.reverse/insn-reverse.c: ... it.
* gdb.reverse/aarch64.exp: Rename to ...
* gdb.reverse/insn-reverse.exp: ... it.
I said we can generialize gdb.reverse/aarch64.exp for other
architectures https://sourceware.org/ml/gdb-patches/2015-05/msg00482.html
and here is the patch to change aarch64.exp so that it can be used to
test for other architectures as well.
gdb/testsuite:
2016-02-26 Yao Qi <yao.qi@linaro.org>
* gdb.reverse/aarch64.c: [__aarch64__] Include arm_neon.h.
(testcase_ftype): New.
(testcases): New array.
(n_testcases): New.
(main): Call each element in testcases.
* gdb.reverse/aarch64.exp: Remove is_aarch64_target check.
(read_testcase): New.
Do the tests in a loop.
Currently, 31-bit gdbserver doesn't support collecting/supplying high
GPRs, VX registers, and TDB data. This is not much of a problem now,
since machines that have them usually have a 64-bit gdbserver that can
be used to debug 31-bit targets just fine. However, with fast
tracepoints, it's not possible to use a 64-bit gdbserver with a 31-bit
IPA (and thus a 31-bit target), so 31-bit gdbserver has to be used
for 31-bit targets. Thus, this patch is needed to allow collecting
high GPRs and VX registers on 31-bit targets via fast tracepoints.
gdb/gdbserver/ChangeLog:
* linux-s390-low.c (s390_num_regs_3264): Define on 31-bit too.
(s390_regmap_3264) [!__s390x__]: New global.
(s390_collect_ptrace_register): Skip map entries containing -1.
(s390_supply_ptrace_register): Ditto.
(s390_fill_gprs_high): New function.
(s390_store_gprs_high): New function.
(s390_regsets): Add NT_S390_HIGH_GPRS.
(s390_get_hwcap): Enable on 31-bit.
(have_hwcap_s390_high_gprs): Enable on 31-bit.
(s390_arch_setup): Enable detection of high GPRs, TDB, VX on 31-bit.
Detect NT_S390_HIGH_GPRS.
(s390_usrregs_info_3264): Enable on 31-bit.
(s390_regs_info): Enable regs_info_3264 on 31-bit.
(initialize_low_arch): Initialize s390_regsets_info_3264 on 31-bit.
This patch removes gdb.base/branches.c which was added by the following
commit, but it is not used at all.
commit ea8122af14
Author: John Metzler <jmetzler@cygnus>
Date: Thu Apr 16 17:56:11 1998 +0000
Thu Apr 16 10:52:34 1998 John Metzler <jmetzler@cygnus.com>
* gdb.base/branches.c: Code with lots of loops and
subroutines. Used to test gdbs ability to single step through PC
changes, especially to test mips-tdep.c:mips_next_pc
gdb/testsuite:
2016-02-25 Yao Qi <yao.qi@linaro.org>
* gdb.base/branches.c: Remove.
If gdbserver and IPA are using different tdesc, they will disagree
about 'R' trace packet size. This results in mangled traces.
To make sure they pick the same tdesc, gdbserver pokes the tdesc
(specified as an index in a target-specific list) into a global
variable in IPA. In theory, IPA could find out the tdesc on its
own, but that may be complex (in particular, I don't know how to
tell whether we have LAST_BREAK on s390 without messing with ptrace),
and we'd have to duplicate the logic.
Tested on i386 and x86_64. On i386, it fixes two FAILs in ftrace.exp.
On x86_64, these failures have been KFAILed - one of them works now,
but the other now fails due to an unrelated reason (ugh).
gdb/gdbserver/ChangeLog:
PR gdb/13808
* Makefile.in: Add i386-*-linux-ipa.o and amd64-*-linux-ipa.o.
* configure.srv: Ditto.
* linux-aarch64-ipa.c (get_ipa_tdesc): New function.
(initialize_low_tracepoint): Remove ipa_tdesc assignment.
* linux-amd64-ipa.c: Add "linux-x86-tdesc.h" include.
(init_registers_amd64_linux): Remove prototype.
(tdesc_amd64_linux): Remove declaration.
(get_ipa_tdesc): New function.
(initialize_low_tracepoint): Remove ipa_tdesc assignment,
initialize remaining tdescs.
* linux-i386-ipa.c: Add "linux-x86-tdesc.h" include.
(init_registers_i386_linux): Remove prototype.
(tdesc_i386_linux): Remove declaration.
(get_ipa_tdesc): New function.
(initialize_low_tracepoint): Remove ipa_tdesc assignment,
initialize remaining tdescs.
* linux-low.c (linux_get_ipa_tdesc_idx): New function.
(linux_target_ops): wire in linux_get_ipa_tdesc_idx.
* linux-low.h (struct linux_target_ops): Add get_ipa_tdesc_idx.
* linux-x86-low.c: Move tdesc declarations to linux-x86-tdesc.h.
(x86_get_ipa_tdesc_idx): New function.
(the_low_target): Wire in x86_get_ipa_tdesc_idx.
* linux-x86-tdesc.h: New file.
* target.h (struct target_ops): Add get_ipa_tdesc_idx.
(target_get_ipa_tdesc_idx): New macro.
* tracepoint.c (ipa_tdesc_idx): New macro.
(struct ipa_sym_addresses): Add addr_ipa_tdesc_idx.
(symbol_list): Add ipa_tdesc_idx.
(cmd_qtstart): Write ipa_tdesc_idx in the target.
(ipa_tdesc): Remove.
(ipa_tdesc_idx): New variable.
(get_context_regcache): Use get_ipa_tdesc.
(gdb_collect): Ditto.
(gdb_probe): Ditto.
* tracepoint.h (get_ipa_tdesc): New prototype.
(ipa_tdesc): Remove.
gdb/testsuite/ChangeLog:
PR gdb/13808
* gdb.trace/ftrace.exp (test_fast_tracepoints): Remove kfail.
We see this error when building with gcc 4.3.
../../gdb/i386-linux-tdep.c: In function ‘i386_linux_handle_segmentation_fault’:
../../gdb/i386-linux-tdep.c:399: error: ‘access’ may be used uninitialized in this function
../../gdb/i386-linux-tdep.c:399: error: ‘upper_bound’ may be used uninitialized in this function
../../gdb/i386-linux-tdep.c:399: error: ‘lower_bound’ may be used uninitialized in this function
It's a false positive, since the variables will always get initialized
in the TRY clause, and the CATCH returns.
gdb/ChangeLog:
* i386-linux-tdep.c (i386_linux_handle_segmentation_fault):
Initialize variables.
The check used hardcoded targets and wasn't doing anything useful anyway,
since unsupported architectures blow up on link due to missing the IPA
library before they ever get to that check.
gdb/testsuite/ChangeLog:
* gdb.trace/ftrace.exp: Remove unnecessary target check.
The PPC64 tracepoint patch added \y at the end of the call_insn pattern -
without that, it embarassed itself and matched the 'bl' in "Dump of
assem*bl*er code for function" as the powerpc call opcode. Since that
sounds like a generally good idea, I've added \y before and after
call_insn for every target. As a result, I had to change x86_64's mnemonic
to 'callq'.
gdb/testsuite/ChangeLog:
* gdb.trace/entry-values.exp: Surround $call_insn with '\y',
change x86_64 call_insn to 'callq'.
When encoding the agent expression operation ax_reg or ax_reg_mask, the
register number used is internal to GDB. However GDBServer expects a tdesc
based number.
This usually does not cause a problem since at the moment, for raw
registers GDBServer R trace action ignores the register mask and just
collects all registers.
It can be a problem, however with pseudo registers on some platforms if the
tdesc number doesn't match the GDB internal register number.
This is the case with ARM, the upcoming ARM tracepoint support, fails
these test cases without this patch:
gdb.trace/collection.exp: collect register locals collectively:*
GDBSever would exit with: unhandled register size
Since the register number is not mapped.
This patch fixes these issues by calling gdbarch_remote_register_number
before encoding the register number in the ax_reg or ax_reg_mask operation.
Tested on x86 native-gdbserver no regressions observed.
gdb/ChangeLog:
* ax-general.c (ax_reg): Call gdbarch_remote_register_number.
(ax_reg_mask): Likewise.
This unbreaks pending/delayed breakpoints handling, as well as
hardware watchpoints, on MIPS.
Ref: https://sourceware.org/ml/gdb-patches/2016-02/msg00681.html
The MIPS kernel reports SI_KERNEL for all kernel generated traps,
instead of TRAP_BRKPT / TRAP_HWBKPT, but GDB isn't aware of this.
Basically, this commit:
- Folds watchpoints logic into check_stopped_by_breakpoint, and
renames it to save_stop_reason.
- Adds GDB_ARCH_IS_TRAP_HWBKPT.
- Makes MIPS set both GDB_ARCH_IS_TRAP_BRPT and
GDB_ARCH_IS_TRAP_HWBKPT to SI_KERNEL. In save_stop_reason, we
handle the case of the same si_code returning true for both
TRAP_BRPT and TRAP_HWBKPT by looking at what the debug registers
say.
Tested on x86-64 Fedora 20, native and gdbserver.
gdb/ChangeLog:
2016-02-24 Pedro Alves <palves@redhat.com>
* linux-nat.c (save_sigtrap) Delete.
(stop_wait_callback): Call save_stop_reason instead of
save_sigtrap.
(check_stopped_by_breakpoint): Rename to ...
(save_stop_reason): ... this. Bits of save_sigtrap folded here.
Use GDB_ARCH_IS_TRAP_HWBKPT and handle ambiguous
GDB_ARCH_IS_TRAP_BRKPT / GDB_ARCH_IS_TRAP_HWBKPT. Factor out
common code between the USE_SIGTRAP_SIGINFO and
!USE_SIGTRAP_SIGINFO blocks.
(linux_nat_filter_event): Call save_stop_reason instead of
save_sigtrap.
* nat/linux-ptrace.h: Check for both SI_KERNEL and TRAP_BRKPT
si_code for MIPS.
* nat/linux-ptrace.h: Fix "TRAP_HWBPT" typo in x86 table. Add
comments on MIPS behavior.
(GDB_ARCH_IS_TRAP_HWBKPT): Define for all archs.
gdb/gdbserver/ChangeLog:
2016-02-24 Pedro Alves <palves@redhat.com>
* linux-low.c (check_stopped_by_breakpoint): Rename to ...
(save_stop_reason): ... this. Use GDB_ARCH_IS_TRAP_HWBKPT and
handle ambiguous GDB_ARCH_IS_TRAP_BRKPT / GDB_ARCH_IS_TRAP_HWBKPT.
Factor out common code between the USE_SIGTRAP_SIGINFO and
!USE_SIGTRAP_SIGINFO blocks.
(linux_low_filter_event): Call save_stop_reason instead of
check_stopped_by_breakpoint and check_stopped_by_watchpoint.
Update comments.
(linux_wait_1): Update comments.
As it is planned to add more architectures to this test, rename to a more
generic name.
gdb/testsuite/ChangeLog:
* gdb.trace/tfile-avx.c: Move to...
* gdb.trace/tracefile-pseudo-reg.c: Here.
* gdb.trace/tfile-avx.exp: Move to...
* gdb.trace/tracefile-pseudo-reg.exp: Here.
Support z-point, so tracepoints and breakpoints can be inserted at the same
location.
gdb/gdbserver/ChangeLog:
2016-02-24 Wei-cheng Wang <cole945@gmail.com>
* linux-ppc-low.c (ppc_supports_z_point_type): New function:
(ppc_insert_point, ppc_remove_point): Insert/remove z-packet breakpoints.
(ppc64_emit_ops_vector): Add target ops - ppc_supports_z_point_type,
ppc_insert_point, ppc_remove_point.
This commit fixes an error in exec_file_locate_attach where
the main executable could be loaded from outside the sysroot
if a nonempty, non-"target:" sysroot was set but the discovered
executable filename did not exist in that sysroot and did exist
on the main filesystem.
gdb/ChangeLog:
* exec.c (exec_file_locate_attach): Do not attempt to
locate main executable locally if not found in sysroot.
gdb/testsuite/ChangeLog:
* gdb.base/attach-pie-noexec.exp: Do not expect an error
message on attach.
gdb/ChangeLog:
Extend "skip" command to support -file, -gfile, -function, -rfunction.
* NEWS: Document new features.
* skip.c: #include "fnmatch.h", "gdb_regex.h".
(skiplist_entry) <file>: Renamed from filename.
<function>: Renamed from function_name.
<file_is_glob, function_is_regexp>: New members.
<compiled_function_regexp, compiled_function_regexp_is_valid>:
New members.
(make_skip_entry): New function.
(free_skiplist_entry, free_skiplist_entry_cleanup): New functions.
(make_free_skiplist_entry_cleanup): New function.
(skip_file_command): Update.
(skip_function, skip_function_command): Update.
(compile_skip_regexp): New functions.
(skip_command): Add support for new options.
(skip_info): Update.
(skip_file_p, skip_gfile_p): New functions.
(skip_function_p, skip_rfunction_p): New functions.
(function_name_is_marked_for_skip): Update and simplify.
(_initialize_step_skip): Update.
* symtab.c: #include "fnmatch.h".
(compare_glob_filenames_for_search): New function.
* symtab.h (compare_glob_filenames_for_search): Declare.
* utils.c (count_path_elements): New function.
(strip_leading_path_elements): New function.
* utils.h (count_path_elements): Declare.
(strip_leading_path_elements): Declare.
gdb/doc/ChangeLog:
* gdb.texinfo (Skipping Over Functions and Files): Document new
options to "skip" command. Update docs of output of "info skip".
gdb/testsuite/ChangeLog:
* gdb.base/skip.c (test_skip): New function.
(end_test_skip_file_and_function): New function.
(test_skip_file_and_function): New function.
* gdb.base/skip1.c (test_skip): New function.
(skip1_test_skip_file_and_function): New function.
* gdb.base/skip.exp: Add tests for new skip options.
* gdb.base/skip-solib.exp: Update expected output.
* gdb.perf/skip-command.cc: New file.
* gdb.perf/skip-command.exp: New file.
* gdb.perf/skip-command.py: New file.
This patch updates the syscalls in sync with syscalls/aarch64-linux.xml.
Some syscalls are still not supported by gdb/linux-record.c yet. Mark
them UNSUPPORTED_SYSCALL_MAP.
This patch fixes the following test fail,
Process record and replay target doesn't support syscall number 56^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0x00000020000e9dfc in open () from /lib/aarch64-linux-gnu/libc.so.6^M
(gdb) FAIL: gdb.reverse/fstatat-reverse.exp: continue to breakpoint: marker2
gdb:
2016-02-23 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-tdep.c (enum aarch64_syscall) <aarch64_sys_mknod>:
Remove.
<aarch64_sys_mkdir, aarch64_sys_unlink, aarch64_sys_symlink>: Remove.
<aarch64_sys_link, aarch64_sys_rename, aarch64_sys_faccess>: Remove.
<aarch64_sys_mknodat, aarch64_sys_mkdirat>: New.
<aarch64_sys_unlinkat, aarch64_sys_symlinkat>: New.
<aarch64_sys_linkat, aarch64_sys_renameat, aarch64_sys_faccessat>: New.
<aarch64_sys_open, aarch64_sys_readlink, aarch64_sys_fstatat>: Remove.
<aarch64_sys_openat, aarch64_sys_readlinkat>: New.
<aarch64_sys_newfstatat>: New.
(UNSUPPORTED_SYSCALL_MAP): New macro.
(aarch64_canonicalize_syscall): Add missing syscalls.
unavailable.exp executes "info registers", expecting to find at least
two instances of "<unavailable>". However, it uses
"<unavailable>.*<unavailable>" as the pattern, which doesn't match
when the last register happens to be available (eg. PC). Change it
to ".*<unavailable>.*<unavailable>.*" instead.
Noticed on s390, no regression on x86_64.
gdb/testsuite/ChangeLog:
* gdb.trace/unavailable.exp (gdb_unavailable_registers_test_1): Fix
info registers pattern.
After building GDB
--with-python=/usr/bin/python3
and for example stripping ./gdb and running:
./gdb -data-directory data-directory/ -iex "add-auto-load-safe-path $PWD/gdb-gdb.gdb" -iex "add-auto-load-safe-path $PWD/gdb-gdb.
py" ./gdb
I get:
Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
File "/home/jkratoch/redhat/gdb-test-python3/gdb/gdb-gdb.py", line 91
print "Warning: Cannot find enum type_flag_value type."
^
SyntaxError: Missing parentheses in call to 'print'
(top-gdb) q
gdb/ChangeLog
2016-02-22 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb-gdb.py (class TypeFlagsPrinter): Use parentheses for print.
This patch fixes the various code format issues in arm process record
in arm-tdep.c, such as using tab instead of spaces.
gdb:
2016-02-22 Yao Qi <yao.qi@linaro.org>
* arm-tdep.c: Fix code format issues.
gdb/testsuite/ChangeLog:
2016-02-18 Wei-cheng Wang <cole945@gmail.com>
* gdb.trace/tspeed.c (myclock): Return wallclock instead of
user+system time.
(trace_speed_test): Determine the iteration count for a time
between 15..30 seconds.
With Intel Memory Protection Extensions it was introduced the concept of
boundary violation. A boundary violations is presented to the inferior as
a segmentation fault having SIGCODE 3. This patch adds a
handler for a boundary violation extending the information displayed
when a bound violation is presented to the inferior. In the stop mode
case the debugger will also display the kind of violation: "upper" or
"lower", bounds and the address accessed.
On no stop mode the information will still remain unchanged. Additional
information about bound violations are not meaningful in that case user
does not know the line in which violation occurred as well.
When the segmentation fault handler is stop mode the out puts will be
changed as exemplified below.
The usual output of a segfault is:
Program received signal SIGSEGV, Segmentation fault
0x0000000000400d7c in upper (p=0x603010, a=0x603030, b=0x603050,
c=0x603070, d=0x603090, len=7) at i386-mpx-sigsegv.c:68
68 value = *(p + len);
In case it is a bound violation it will be presented as:
Program received signal SIGSEGV, Segmentation fault
Upper bound violation while accessing address 0x7fffffffc3b3
Bounds: [lower = 0x7fffffffc390, upper = 0x7fffffffc3a3]
0x0000000000400d7c in upper (p=0x603010, a=0x603030, b=0x603050,
c=0x603070, d=0x603090, len=7) at i386-mpx-sigsegv.c:68
68 value = *(p + len);
In mi mode the output of a segfault is:
*stopped,reason="signal-received",signal-name="SIGSEGV",
signal-meaning="Segmentation fault", frame={addr="0x0000000000400d7c",
func="upper",args=[{name="p", value="0x603010"},{name="a",value="0x603030"}
,{name="b",value="0x603050"}, {name="c",value="0x603070"},
{name="d",value="0x603090"},{name="len",value="7"}],
file="i386-mpx-sigsegv.c",fullname="i386-mpx-sigsegv.c",line="68"},
thread-id="1",stopped-threads="all",core="6"
in the case of a bound violation:
*stopped,reason="signal-received",signal-name="SIGSEGV",
signal-meaning="Segmentation fault",
sigcode-meaning="Upper bound violation",
lower-bound="0x603010",upper-bound="0x603023",bound-access="0x60302f",
frame={addr="0x0000000000400d7c",func="upper",args=[{name="p",
value="0x603010"},{name="a",value="0x603030"},{name="b",value="0x603050"},
{name="c",value="0x603070"},{name="d",value="0x603090"},
{name="len",value="7"}],file="i386-mpx-sigsegv.c",
fullname="i386-mpx-sigsegv.c",line="68"},thread-id="1",
stopped-threads="all",core="6"
2016-02-18 Walfred Tedeschi <walfred.tedeschi@intel.com>
gdb/ChangeLog:
* NEWS: Add entry for bound violation.
* amd64-linux-tdep.c (amd64_linux_init_abi_common):
Add handler for segmentation fault.
* gdbarch.sh (handle_segmentation_fault): New.
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* i386-linux-tdep.c (i386_linux_handle_segmentation_fault): New.
(SIG_CODE_BONDARY_FAULT): New define.
(i386_linux_init_abi): Use i386_mpx_bound_violation_handler.
* i386-linux-tdep.h (i386_linux_handle_segmentation_fault) New.
* i386-tdep.c (i386_mpx_enabled): Add as external.
* i386-tdep.c (i386_mpx_enabled): Add as external.
* infrun.c (handle_segmentation_fault): New function.
(print_signal_received_reason): Use handle_segmentation_fault.
gdb/testsuite/ChangeLog:
* gdb.arch/i386-mpx-sigsegv.c: New file.
* gdb.arch/i386-mpx-sigsegv.exp: New file.
* gdb.arch/i386-mpx-simple_segv.c: New file.
* gdb.arch/i386-mpx-simple_segv.exp: New file.
gdb/doc/ChangeLog:
* gdb.texinfo (Signals): Add bound violation display hints for
a SIGSEGV.
When we're looking at a tracefile trace frame where registers are not
available, and the tracepoint has only one location, we supply
the location's address as the PC register. However, this only works
if PC is not a pseudo register, and individual architectures may want
to guess more registers. Add a gdbarch hook that will handle that.
gdb/ChangeLog:
* arch-utils.c (default_guess_tracepoint_registers): New function.
* arch-utils.h (default_guess_tracepoint_registers): New prototype.
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh: Add guess_tracepoint_registers hook.
* tracefile.c (tracefile_fetch_registers): Use the new gdbarch hook.
This patch series add fork support in target remote,
[PATCH v2 0/3] Target remote mode fork and exec support
https://sourceware.org/ml/gdb-patches/2015-12/msg00144.html
so GDB can be informed about the child, and adjust child correctly in
displaced stepping. The PR server/13796 was fixed by this patch
series actually. Test results on buildbot show this KFAIL->KPASS
change https://sourceware.org/ml/gdb-testers/2015-q4/msg10128.html
gdb/testsuite:
2016-02-18 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-syscall.exp (disp_step_cross_syscall):
Don't call setup_kfail.
Proc do_test in forking-threads-plus-breakpoint.exp has an argument
cond_bp_target, but the test doesn't use it to set
"breakpoint condition-evaluation", which is an oversight in the test.
This patch fixes it by setting "breakpoint condition-evaluation" per
$cond_bp_target.
gdb/testsuite:
2016-02-18 Yao Qi <yao.qi@linaro.org>
* gdb.threads/forking-threads-plus-breakpoint.exp (do_test):
Set "set breakpoint condition-evaluation" per $cond_bp_target.
exec_file_locate_attach allocates memory for full_exec_path (using
either exec_file_find, source_full_path_of or xstrdup) but this
memory is never freed. This commit adds the necessary cleanup.
gdb/ChangeLog:
* exec.c (exec_file_locate_attach): Add missing cleanup.
This is necessary for upcoming tracepoint support - otherwise, setting
a tracepoint and a breakpoint on the same address will fail, since gdbserver
won't know about gdb's breakpoint.
Tested on s390x-ibm-linux-gnu and s390-ibm-linux-gnu, RHEL 7.2.
gdb/gdbserver/ChangeLog:
* linux-s390-low.c (s390_supports_z_point_type): New function.
(struct linux_target_ops): Wire s390_supports_z_point_type in.
This patch fixes an internal error that occurs in
gdb.threads/forking-threads-plus-breakpoint.exp:
/blah/binutils-gdb/gdb/target.c:2723: internal-error: Can't determine the
current address space of thread Thread 3170.3170
In default_thread_address_space, find_inferior_ptid couldn't find 3170.3170
because it had been overwritten in inferior_appeared, called as follows:
inferior_appeared
remote_add_inferior
remote_notice_new_inferior
remote_update_thread_list
The cause of the problem was the following sequence of events:
* GDB knows only about the main thread
* the first fork event is reported to GDB, saved as pending_event
* qXfer:threads:read gets the threads from the remote.
remove_new_fork_children id's the fork child from the pending event
and removes it from the list reported to GDB. All the rest of the
threads, including the fork parent, are added to the GDB thread list.
* GDB stops all the threads. All the stop events are pushed onto the
stop reply queue behind the pending fork event. The fork waitstatus
is saved in the fork parent thread's pending status field
thread_info.suspend.
* remote_wait_ns calls queued_stop_reply and process_stop_reply to
remove the fork event from the front of the stop reply queue and save
event information in the thread_info structure for the fork parent
thread. Unfortunately, none of the information saved in this way is
the fork-specific information.
* A subsequent qXfer:threads:read packet gets the thread list including
the fork parent and fork child. remove_new_fork_children checks the
thread list to see if there is a fork parent, doesn't find one, checks
the stop reply queue for a pending fork event, doesn't find one, and
allows the fork child thread to be reported to GDB before the fork
event has been handled. remote_update_thread_list calls
remote_notice_new_thread and overwrites the current (main) thread in
inferior_appeared.
So the fork event has been reported out of target_wait but it was left
pending on the infrun side (infrun.c:save_waitstatus). IOW, the fork
event hasn't been processed by handle_inferior_event yet, so it hasn't
made it to tp->pending_follow yet.
The fix is to check thread_info.suspend along with the
thread_info.pending_follow in remote.c:remove_new_fork_children, to
prevent premature reporting of the fork child thread creation.
gdb/ChangeLog:
PR remote/19496
* remote.c (remove_new_fork_children): Check for pending
fork status in thread_info.suspend.
gdb/testsuite/ChangeLog:
PR remote/19496
* gdb.threads/forking-threads-plus-breakpoint.exp (do_test):
Remove kfail for PR remote/19496.
Just like standard_output_file, standard_temp_file should use multiple
directories to make the tests parallel-safe. However,
standard_temp_file is sometimes called in some procedures that are not
test-specific. For example, gdb_init uses it, but is called once before
all test files are ran. Therefore, we can't organize it in a
temp/gdb.subdir/testname layout, like standard_output_file.
Because it's just meant for temporary files that don't really need to be
inspected after the test, we can just put them in a directory based on
the runtest pid. There is always a single exp file being executed by a
particular runtest invocation at any given time, so it should be safe.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (standard_temp_file): Return a path specific to
the runtest invocation.
In save-trace.exp, we want to test loading of a tracepoint definition
file with a relative path (I am not sure why in fact). We currently use
"savetrace-relative.tr", which ends up directly in testsuite/. If we
use [standard_output_file] on that path, it becomes absolute. I decided
to just replace [pwd] with . (a dot) in the path given by
standard_output_file to make it relative. However, this trick only
works because [pwd] is a prefix of the standard output directory. So I
added a check to verify that precondition.
gdb/testsuite/ChangeLog:
* gdb.trace/save-trace.exp: Change relative path to be in the
standard output directory.
I see the following error in testing aarch64 GDB debugging arm
program.
(gdb) PASS: gdb.reverse/readv-reverse.exp: set breakpoint at marker2
continue
Continuing.
=================================================================
==32273==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x000000ce4c00 in thread T0
#0 0x2ba5615645c7 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x545c7)^M
#1 0x4be8b5 in VEC_CORE_ADDR_cleanup /home/yao/SourceCode/gnu/gdb/git/gdb/common/gdb_vecs.h:34^M
#2 0x5e6d95 in do_my_cleanups /home/yao/SourceCode/gnu/gdb/git/gdb/common/cleanups.c:154^M
#3 0x64c99a in fetch_inferior_event /home/yao/SourceCode/gnu/gdb/git/gdb/infrun.c:3975^M
#4 0x678437 in inferior_event_handler /home/yao/SourceCode/gnu/gdb/git/gdb/inf-loop.c:44^M
#5 0x5078f6 in remote_async_serial_handler /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:13223^M
#6 0x4cecfd in run_async_handler_and_reschedule /home/yao/SourceCode/gnu/gdb/git/gdb/ser-base.c:137^M
#7 0x676864 in gdb_wait_for_event /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:834^M
#8 0x676a27 in gdb_do_one_event /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:323^M
#9 0x676aed in start_event_loop /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:347^M
#10 0x6706d2 in captured_command_loop /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:318^M
#11 0x66db8c in catch_errors /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:240^M
#12 0x6716dd in captured_main /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:1157^M
#13 0x66db8c in catch_errors /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:240^M
#14 0x671b7a in gdb_main /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:1165^M
#15 0x467684 in main /home/yao/SourceCode/gnu/gdb/git/gdb/gdb.c:32^M
#16 0x2ba563ed7ec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)^M
#17 0x4676b2 (/scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/gdb+0x4676b2)
looks we should discard cleanup if function
arm_linux_software_single_step returns early, or create cleanup when
it is needed.
gdb:
2016-02-16 Yao Qi <yao.qi@linaro.org>
* arm-linux-tdep.c (arm_linux_software_single_step): Assign
'old_chain' later.
Method syscall_next_pc of struct arm_get_next_pcs_ops has an argument
PC, which is not necessary, because PC can be got from regcache in
'struct arm_get_next_pcs'. This patch removes the PC argument of
syscall_next_pc.
gdb:
2016-02-16 Yao Qi <yao.qi@linaro.org>
* arch/arm-get-next-pcs.h (struct arm_get_next_pcs_ops)
<syscall_next_pc>: Remove argument PC. Callers updated.
* arm-linux-tdep.c (arm_linux_get_next_pcs_syscall_next_pc):
Remove argument PC. Get pc from regcache_read_pc.
* arm-tdep.c (arm_get_next_pcs_syscall_next_pc): Remove
argument PC.
gdb/gdbserver:
2016-02-16 Yao Qi <yao.qi@linaro.org>
* linux-arm-low.c (get_next_pcs_syscall_next_pc): Remove argument
PC. Get pc from regcache_read_pc.
The testfile has not ran because:
gdb.arch/i386-prologue.c:34:3: warning: implicit declaration of function 'standard' [-Wimplicit-function-declaration]
standard ();
^
gdb.arch/i386-prologue.c:35:3: warning: implicit declaration of function 'stack_align_ecx' [-Wimplicit-function-declaration]
stack_align_ecx ();
^
gdb.arch/i386-prologue.c:36:3: warning: implicit declaration of function 'stack_align_edx' [-Wimplicit-function-declaration]
stack_align_edx ();
^
gdb.arch/i386-prologue.c:37:3: warning: implicit declaration of function 'stack_align_eax' [-Wimplicit-function-declaration]
stack_align_eax ();
^
gdb/testsuite/ChangeLog
2016-02-15 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.arch/i386-prologue.c: Add missing prototypes.
Since
commit 2151ccc56c
Author: Simon Marchi <simon.marchi@ericsson.com>
Date: Mon Feb 8 14:02:36 2016 -0500
Always organize test artifacts in a directory hierarchy
these testfiles could not build.
gdb/testsuite/ChangeLog
2016-02-15 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.arch/i386-gnu-cfi.exp: Use standard_output_file.
* gdb.arch/i386-prologue.exp: Likewise.
* gdb.arch/i386-size.exp: Likewise.
gdb/testsuite/ChangeLog:
* gdb.base/wrong_frame_bt_full.exp: Use standard_output_file to
define object file path.
* gdb.btrace/gcore.exp: Use standard_output_file to define core
file path.
* lib/opencl.exp (gdb_compile_opencl_hostapp): Use
standard_output_file to define binfile.
core_addr_to_string_nz returns string which has "0x" prefix, so don't
need to print "0x" again. This patch is to remove the "0x".
gdb:
2016-02-15 Yao Qi <yao.qi@linaro.org>
* aarch64-tdep.c (aarch64_analyze_prologue): Remove "0x".
gcc-4.9.2-6.fc21.x86_64 -> gcc-5.3.1-2.fc23.x86_64
-PASS: gdb.fortran/vla-ptype.exp: ptype pvla not initialized
+FAIL: gdb.fortran/vla-ptype.exp: ptype pvla not initialized
-PASS: gdb.fortran/vla-history.exp: print vla1 allocated
+FAIL: gdb.fortran/vla-history.exp: print vla1 allocated
-PASS: gdb.fortran/vla-history.exp: print $2
+FAIL: gdb.fortran/vla-history.exp: print $2
-PASS: gdb.fortran/vla-value.exp: print undefined pvla
+FAIL: gdb.fortran/vla-value.exp: print undefined pvla
-PASS: gdb.fortran/vla-value.exp: print non-associated &pvla
+FAIL: gdb.fortran/vla-value.exp: print non-associated &pvla
-PASS: gdb.fortran/vla-value.exp: print undefined pvla(1,3,8)
+FAIL: gdb.fortran/vla-value.exp: print undefined pvla(1,3,8)
These issues get fixed (or removed if no longer applicable) by attached patch.
It is based on Googled:
http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html#5
When a pointer is declared its status is undefined, and cannot be
safely queried with the associated intrinsic.
-> nullify(VARNAME)
+
https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/268786
ALLOCATE is not supposed to initialize the array.
-> Remove checks like an initial print is: \\( *0, *0, *0...\\)
These regressions remain:
-PASS: gdb.fortran/library-module.exp: print var_i in lib
+FAIL: gdb.fortran/library-module.exp: print var_i in lib
-PASS: gdb.fortran/library-module.exp: print var_i in main
+FAIL: gdb.fortran/library-module.exp: print var_i in main
I believe it is more a GDB bug (in a code contributed by me), filed:
gdb.fortran/library-module.exp false regression on GCC upgrade
https://sourceware.org/bugzilla/show_bug.cgi?id=19635
gdb/testsuite/ChangeLog
2016-02-14 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix compatibility with recent gfortran-5.3.1.
* gdb.fortran/vla-history.exp (print vla1 allocated)
(print vla2 allocated, print $2, print $3): Remove
(print $4): Rename to ...
(print $2): ... here.
(print $9): Rename to ...
(print $5): ... here.
(print $10): Rename to ...
(print $6): ... here.
* gdb.fortran/vla.f90: Add pvla initialization.
> +static int max_value_size = 65536; /* 64k bytes */
FAIL: gdb.fortran/vla-value-sub.exp: print array2 in foo after it was filled (passed fixed array)
FAIL: gdb.fortran/vla-value-sub.exp: print array2 in foo after it was mofified in debugger (passed fixed array)
FAIL: gdb.fortran/vla-value-sub-finish.exp: print array2 in foo after it was filled
FAIL: gdb.fortran/vla-value-sub-finish.exp: print array2 in foo after it was mofified in debugger
print array2
value requires 296352 bytes, which is more than max-value-size
(gdb) FAIL: gdb.fortran/vla-value-sub.exp: print array2 in foo after it was filled (passed fixed array)
gdb/testsuite/ChangeLog
2016-02-14 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.fortran/vla-value-sub-finish.exp (set max-value-size 1024*1024):
New test.
* gdb.fortran/vla-value-sub.exp: Likewise.
gcc older than 4.9 doesn't understand ymm15 as a register name. Use
xmm15 instead.
gdb/testsuite/ChangeLog:
* gdb.trace/tfile-avx.c (main): Change ymm15 to xmm15.
Fix the core file path to use the standard output directory.
gdb/testsuite/ChangeLog:
* i386-biarch-core.exp: Define corefile using
standard_output_file.
We can use shared functions linux_{set,get}_pc_{64,32}bit in
linux-aarch64-low.c to write and read pc.
gdb/gdbserver:
2016-02-12 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_get_pc): Call linux_get_pc_64bit
or linux_get_pc_32bit.
(aarch64_set_pc): Call linux_set_pc_64bit or linux_set_pc_32bit.
GDB step cross kernel helpers only works if the kernel helpers are tail
called, which is the case how it is used in glibc. See __aeabi_read_tp
in sysdeps/unix/sysv/linux/arm/aeabi_read_tp.S. In __aeabi_read_tp,
branch/jump to the kernel helper is the last instruction, and the next
instruction address is in LR, which is in caller function. GDB can
handle this correctly. For example, glibc function __GI___ctype_init
calls __aeabi_read_tp
0xb6e19b30 <__GI___ctype_init+4>: ldr r3, [pc, #80] ;
0xb6e19b34 <__GI___ctype_init+8>: bl 0xb6e0a6e0 <__aeabi_read_tp>
0xb6e19b38 <__GI___ctype_init+12>: ldr r3, [pc, r3]
and __aeabi_read_tp calls kernel helper,
(gdb) disassemble __aeabi_read_tp
0xb6fef5d0 <+0>: mvn r0, #61440 ; 0xf000
0xb6fef5d4 <+4>: sub pc, r0, #31
once GDB or GDBserver single step instruction on 0xb6fef5d4, LR is
0xb6e19b38, which is right address of next instruction to set breakpoint
on.
However, if the kernel helpers are not tail-called, the LR is still the
address in the caller function of kernel helper's caller, which isn't
the right address of next instruction to set breakpoint on. For example,
we use kernel helper in main,
(gdb) disassemble main
....
0x00008624 <+32>: mov r3, #4064 ; 0xfe0^M
0x00008628 <+36>: movt r3, #65535 ; 0xffff^M
0x0000862c <+40>: blx r3
0x00008630 <+44>: ldr r3, [r11, #-8]
kernel helper is called on 0x0000862c and the expected next instruction
address is 0x00008630, but the LR now is the return address of main.
The problem here is LR may not have the right address because when we
single step the instruction, it isn't executed yet, so the LR isn't
updated. This patch fix this problem by decoding instruction, if the
instruction updates LR (BL and BLX), the next instruction address is
PC + INSN_SIZE, otherwise, get the address of next instruction from LR.
gdb:
2016-02-12 Yao Qi <yao.qi@linaro.org>
* arch/arm-linux.c (arm_linux_get_next_pcs_fixup): Calculate
nextpc according to instruction.
gdb/testsuite:
2016-02-12 Yao Qi <yao.qi@linaro.org>
* gdb.arch/arm-single-step-kernel-helper.c: New.
* gdb.arch/arm-single-step-kernel-helper.exp: New.
When I exercise GDBserver software single step, I see the following
error, which has been already handled by GDB properly.
In GDBserver log, we can see, GDBserver tries to single step instruction
on 0xb6e0a6e4, and destination address is 0xffff0fe0,
stop pc is 0xb6e0a6e4
Writing f001f0e7 to 0xffff0fe0 in process 7132
Failed to insert breakpoint at 0xffff0fe0 (Input/output error).
Failed to insert breakpoint at 0xffff0fe0 (-1).
(gdb) disassemble __aeabi_read_tp,+8
Dump of assembler code from 0xb6e0a6e0 to 0xb6e0a6e8:
0xb6e0a6e0 <__aeabi_read_tp+0>: mvn r0, #61440 ; 0xf000
0xb6e0a6e4 <__aeabi_read_tp+4>: sub pc, r0, #31
however, it fails inserting breakpoint there. This problem has already
fixed by GDB, see comments in arm-linux-tdep.c:arm_linux_software_single_step
/* The Linux kernel offers some user-mode helpers in a high page. We can
not read this page (as of 2.6.23), and even if we could then we
couldn't set breakpoints in it, and even if we could then the atomic
operations would fail when interrupted. They are all called as
functions and return to the address in LR, so step to there
instead. */
so we need to do the same thing in GDB side as well. This patch adds
a new field fixup in arm_get_next_pcs_ops, so that we can fix up PC
for arm-linux target. In this way, both GDB and GDBserver can single
step instructions going to kernel helpers.
gdb:
2016-02-12 Yao Qi <yao.qi@linaro.org>
* arch/arm-get-next-pcs.c (arm_get_next_pcs): Call
self->ops->fixup if it isn't NULL.
* arch/arm-get-next-pcs.h: Include gdb_vecs.h.
(struct arm_get_next_pcs_ops) <fixup>: New field.
* arch/arm-linux.c: Include common-regcache.h and
arch/arm-get-next-pcs.h.
(arm_linux_get_next_pcs_fixup): New function.
* arch/arm-linux.h (arm_linux_get_next_pcs_fixup): Declare.
* arm-linux-tdep.c (arm_linux_get_next_pcs_ops): Initialize
it with arm_linux_get_next_pcs_fixup.
(arm_linux_software_single_step): Move code to
arm_linux_get_next_pcs_fixup.
* arm-tdep.c (arm_get_next_pcs_ops): Initialize it.
gdb/gdbserver:
2016-02-12 Yao Qi <yao.qi@linaro.org>
* linux-arm-low.c (get_next_pcs_ops): Initialize it with
arm_linux_get_next_pcs_fixup.
This function is now basically identical to write_inferior_data_pointer,
remove it and change all references.
gdb/gdbserver/ChangeLog:
* tracepoint.c (x_tracepoint_action_download): Change
write_inferior_data_ptr to write_inferior_data_pointer.
(cmd_qtstart): Likewise.
(write_inferior_data_ptr): Remove.
(download_agent_expr): Change write_inferior_data_ptr to
write_inferior_data_pointer.
(download_tracepoint_1): Likewise.
(download_tracepoint): Likewise.
(download_trace_state_variables): Likewise.
In skip_artificial_frames we repeatedly call get_prev_frame_always until we get
a non-inline and non-tailcall frame assuming that there must be such a frame
eventually.
For record targets, however, we may have a frame chain that consists only of
artificial frames. This leads to a crash in get_frame_type when dereferencing a
NULL frame pointer.
Change skip_artificial_frames and skip_tailcall_frames to return NULL in such a
case and modify each caller to cope with a NULL return.
In frame_unwind_caller_pc and frame_unwind_caller_arch, we simply assert that
the returned value is not NULL. Their caller was supposed to check
frame_unwind_caller_id before calling those functions.
In other cases, we thrown an error.
In infcmd further move the skip_tailcall_frames call to the forward-stepping
case since we don't need a frame for reverse execution and we don't want to fail
because of that. Reverse-finish does make sense for a tailcall frame.
gdb/
* frame.h (skip_tailcall_frames): Update comment.
* frame.c (skip_artificial_frames, skip_tailcall_frames): Return NULL
if only artificial frames are found. Update comment.
(frame_unwind_caller_id): Handle NULL return.
(frame_unwind_caller_pc, frame_unwind_caller_arch): Assert that
skip_artificial_frames does not return NULL.
(frame_pop): Add an error if only tailcall frames are found.
* infcmd.c (finish_command): Move skip_tailcall_frames call into forward-
execution case. Add an error if only tailcall frames are found.
testsuite/
* gdb.btrace/tailcall-only.exp: New.
* gdb.btrace/tailcall-only.c: New.
* gdb.btrace/x86_64-tailcall-only.S: New.
* gdb.btrace/i686-tailcall-only.S: New.
Callers of frame_unwind_caller_* functions are supposed to check
frame_unwind_caller_id.
Add such a check to frame_info and treat an invalid caller ID as if the caller
PC were not available.
gdb/
* stack.c (frame_info): Check frame_unwind_caller_id.
This patch removes 'ops' in tracepoint, and uses helper functions to
call action handler instead.
The object layout of tracepoint_action may differ in gdbserver and
inferior depend on the alignment rule of target ABI, so gdbserver cannot
simply copy the object from its memory to inferior memory.
For example,
struct collect_memory_action
{
struct tracepoint_action base;
{
#ifndef IN_PROCESS_AGENT
const struct tracepoint_action_ops *ops;
#if
- char type;
| }
| ULONGEST addr;
| ULONGEST len;
- int32_t basereg;
};
and on PowerPC,
Wihtout ops with ops
0 1 2 3 0 1 2 3
0 |type| PADDING... 0 |ops-------------|
4 ................. 4 |type|PADDING....|
8 |addr------------ 8 |addr-------------
c ----------------| c -----------------|
10 |len------------- 10 |len--------------
14 ----------------| 14 -----------------|
18 |basereg--------| 18 |basereg---------|
so we cannot directly copy the object.
In this patch, 'ops' is removed in order to make the objects identical.
gdb/gdbserver/ChangeLog:
2016-02-11 Wei-cheng Wang <cole945@gmail.com>
Marcin Kościelnicki <koriakin@0x04.net>
* tracepoint.c (struct tracepoint_action_ops): Remove.
(struct tracepoint_action): Remove ops.
(m_tracepoint_action_download, r_tracepoint_action_download)
(x_tracepoint_action_download, l_tracepoint_action_download): Adjust
size and offset accordingly.
(m_tracepoint_action_ops, r_tracepoint_action_ops)
(x_tracepoint_action_ops, l_tracepoint_action_ops): Remove.
(tracepoint_action_send, tracepoint_action_download): New functions.
Helpers for trace action handlers.
(add_tracepoint_action): Remove setup actions ops.
(download_tracepoint_1, tracepoint_send_agent): Call helper functions.
Currently, you can cd to the gdb/testsuite/ dir and use
make check-parallel, instead of using FORCE_PARALLEL:
$ make -j8 check-parallel RUNTESTFLAGS="--target_board=native-gdbserver"
$ make -j8 check RUNTESTFLAGS="--target_board=native-gdbserver" FORCE_PARALLEL=1
But you can't do that in the build/gdb/ dir:
$ make check-parallel RUNTESTFLAGS="--target_board=native-gdbserver"
make: *** No rule to make target `check-parallel'. Stop.
I find check-parallel a bit more convenient, and more typo-proof, so
this patch makes it work from the gdb build dir too.
While documenting this in testsuite/README, I found that the parallel
testing mode would better be pulled out to its own section and
extended.
gdb/ChangeLog:
2016-02-11 Pedro Alves <palves@redhat.com>
* Makefile.in (check-parallel): New rule.
gdb/testsuite/ChangeLog:
2016-02-11 Pedro Alves <palves@redhat.com>
* README (Parallel testing): New section.
(GDB_PARALLEL): Rewrite.
(FORCE_PARALLEL): Document.
This function is never used, since it is superseded by
arm_linux_displaced_step_copy_insn.
gdb/ChangeLog:
* arm-tdep.c (arm_displaced_step_copy_insn): Remove.
(ARM displaced stepping support): Remove reference to
arm_displaced_step_copy_insn in comment.
* arm-tdep.h (arm_displaced_step_copy_insn): Remove.
* arm-linux-tdep.c (arm_linux_displaced_step_copy_insn): Remove
reference to arm_displaced_step_copy_insn in comment.
Almost obvious... change the type of some insn parameters, so that it
matches the rest of the code.
gdb/ChangeLog:
* arm-tdep.c (thumb_copy_unmodified_16bit): Change type of insn.
(thumb_copy_b): Likewise.
(arm_decode_b_bl_ldmstm): Likewise.
(thumb_copy_16bit_ldr_literal): Likewise.
(thumb_copy_pop_pc_16bit): Likewise.
This tests whether $ymm15 can be correctly collected and printed from
tfile. It covers:
- storing tdesc in tfile (without that, $ymm15 doesn't exist)
- ax_pseudo_register_collect for x86 (without that, $ymm15 cannot be
collected)
- register order in tfile_fetch_registers (without that, $ymm15h is
fetched from wrong position)
- off-by-one in tfile_fetch_registers (without that, $ymm15h is
incorrectly considered to be out of bounds)
- using proper tdesc in encoding tracepoint actions (without that,
internal error happens due to $ymm15h being considered unavailable)
gdb/testsuite/ChangeLog:
* gdb.trace/tfile-avx.c: New test.
* gdb.trace/tfile-avx.exp: New test.
This patch uses the target architecture rather then the objfile
architecture when encoding tracepoint actions.
The target architecture may contain additional registers. E.g. ARM VFP
registers. This information is needed to allow their collection. Since we
can never know whether the registers numbers in the target match the
binary's we have to use tdesc here.
One note about combined debuggers / multi-inferior from Pedro Alves:
In the combined debugger case taking Cell as the practical example that
gdb supports currently:
In that case, the main target_gdbarch() will be powerpc, but you may have set a
tracepoint on _spu_ code, which has a different gdbarch. so for that case,
target_gdbarch would be wrong. I think that in that case, we'd need to
find __the_ target/tdesc gdbarch that is (bfd) compatible with the
objfile's gdbarch.
I think cell/spu gdbserver doesn't support tracepoints, so we can ignore
this for now.
The multi-inferior/process case is somewhat related, but its simpler.
each inferior has its own gdbarch.
That is, target_gdbarch depends on the current inferior selected.
In fact, that just returns inferior->gdbarch nowaways.
No regressions, tested on ubuntu 14.04 ARMv7 and x86.
With gdbserver-{native,extended} / { -marm -mthumb }
gdb/ChangeLog:
* tracepoint.c (encode_actions_1): Use target_gdbarch () rather
than loc->gdbarch.
We have function regcache_raw_read_unsigned defined in both GDB and
GDBserver, so that it is used in common like this,
ULONGEST value;
status = regcache_raw_read_unsigned (regcache, regnum, &value);
'value' is correctly set in GDB side, but may not be correctly set
in GDBserver, because &value is passed in regcache_raw_read_unsigned
but collect_register may only set part of the whole variable. In my
test, I see the top half of 'value' is garbage. This patch fixes this
problem by clearing *VAL before calling collect_register.
gdb/gdbserver:
2016-02-10 Yao Qi <yao.qi@linaro.org>
* regcache.c (regcache_raw_read_unsigned): Clear *VAL.
tfile_fetch_registers currently wrongly fetches registers using
gdb order instead of g packet order. On x86_64 with AVX, this causes
problems with ymm*h and orig_rax registers: gdb has ymm*h first, while
g packet has orig_rax first.
gdb/ChangeLog:
* tracefile-tfile.c (tfile_fetch_registers): Use g packet order
instead of gdb order.
gdb/doc/ChangeLog:
* gdb.texinfo (Trace File Format): Remove misleading information
about register block ordering.
This resulted in the last register being considered unavailable.
On plain x86_64 (without AVX), this happened to be orig_rax.
gdb/ChangeLog:
* tracefile-tfile.c (tfile_fetch_registers): Fix off-by-one in bounds
check.
Now that the GDB 7.11 branch has been created, we can
bump the version number.
gdb/ChangeLog:
GDB 7.11 branch created (9ef9e6a6a0):
* version.in: Bump version to 7.11.50.DATE-git.
One of the last checks update_breakpoints_after_exec does while looping
over the list of breakpoints is check that the breakpoint has a valid
location spec. It uses event_location_empty_p to check if the location spec
is "empty", and if it is, the breakpoint is deleted.
momentary_breakpoint types rely on setting the breakpoint structure's
location spec to NULL, thereby causing an update to delete the breakpoint.
However, event_location_empty_p assumed that locations were never NULL.
As a result, GDB would crash dereferencing a NULL pointer whenever
update_breakpoints_after_exec would encounter a momentary_breakpoint.
This patch creates a new wrapper/helper function which tests that the given
breakpoint's location spec is non-NULL and if it is not "empty"
or "unspecified."
gdb/ChangeLog
PR breakpoints/19546
* breakpoint.c (breakpoint_event_location_empty_p): New function.
(update_breakpoints_after_exec, bkpt_re_set): Use this new function
instead of event_location_empty_p.
gdb/testsuite/ChangeLog
PR breakpoints/19546
* gdb.base/infcall-exec.c: New file.
* gdb.base/infcall-exec2.c: New file.
* gdb.base/infcall-exec.exp: New file.
