HP-UX and SGI/IRIX are no longer supported. Remove references
throughout.
AFAICS from the sources, "catch fork" seems to be supported in
multiple Unix systems -- just remove the "only works on xxx" remarks.
Update the list of supported shared library types.
gdb/doc/ChangeLog:
* gdb.texinfo (Threads): Remove mention of SGI.
(Forks): Remove mention of HP-UX.
(Breakpoints): Remove mention of HP-UX.
(Set Watchpoints) <hardware watchpoints>: Don't mention HP-UX.
Reword in terms of architectures.
(Set Catchpoints) <catch exec, catch fork, catch vfork>: Don't
mention supported systems.
(Convenience Vars): Don't mention HP-UX.
(Jumping): Remove mention of HP-UX in comment.
(Files) <shared libraries>: Update supported shared library types
list. Remove mention of HP-UX.
(Native): Remove HP-UX subsection.
(SVR4 Process Information): Remove mention of HP-UX.
I think these references to "spaces" came from the original multi-exec
submission that exposed "symbol spaces" to the user and had a
different UI, and then survived a global find/replace.
gdb/testsuite/ChangeLog:
2015-12-10 Pedro Alves <palves@redhat.com>
* gdb.multi/base.exp: Remove stale "spaces" references.
Several of the gdb.multi tests use the "nowarnings" option to suppress
warnings. The warnings in question all come from missing headers,
like e.g.:
src/gdb/testsuite/gdb.multi/multi-arch-exec.c:28:3: warning: incompatible implicit declaration of built-in function 'exit' [enabled by default]
exit (1);
^
There's no point in trying to avoid to include standard headers. In
gdb.base/hangout.c's case, it's even dangerous, as that file calls
printf. In order to compile a call to a variatic function correctly,
a declaration must be visible.
gdb/testsuite/ChangeLog:
2015-12-10 Pedro Alves <palves@redhat.com>
* gdb.multi/base.exp: Don't use nowarnings.
* gdb.multi/bkpt-multi-exec.exp: Don't use nowarnings.
* gdb.multi/hangout.c: Include stdio.h.
* gdb.multi/hello.c: Include stdlib.h.
* gdb.multi/multi-arch-exec.c: Include stdlib.h.
* gdb.multi/multi-arch-exec.exp: Don't use nowarnings.
* gdb.multi/multi-arch.exp: Don't use nowarnings.
Before, on systems that did not support PTRACE_EVENT_CLONE, both GDB and
GDBServer coordinated with libthread_db.so to insert breakpoints at magic
locations in libpthread.so, in order to break at thread creation and
thread death.
Support for thread events was removed from GDBServer as patch:
https://sourceware.org/ml/gdb-patches/2015-11/msg00466.html
This patch removes support for thread events in GDB.
No regressions found on Ubuntu 14.04 x86_64.
gdb/ChangeLog:
* breakpoint.c (remove_thread_event_breakpoints): Remove.
* breakpoint.h (remove_thread_event_breakpoints): Remove
declaration.
* linux-nat.c (in_pid_list_p): Remove.
(lin_lwp_attach_lwp): Remove.
* linux-nat.h (lin_lwp_attach_lwp): Remove declaration.
* linux-thread-db.c (thread_db_use_events): Remove.
(struct thread_db_info) <td_create_bp_addr>: Remove.
<td_death_bp_addr>: Likewise.
<td_ta_event_addr_p>: Likewise.
<td_ta_set_event_p>: Likewise.
<td_ta_clear_event_p>: Likewise.
<td_ta_event_getmsg_p>: Likewise.
<td_thr_event_enable_p>: Likewise.
(attach_thread): Likewise.
(detach_thread): Likewise.
(have_threads_callback): Likewise.
(have_threads): Likewise.
(enable_thread_event): Likewise.
(enable_thread_event_reporting): Likewise.
(try_thread_db_load_1): Remove td_ta_event_addr, td_ta_set_event,
td_ta_clear_event, td_ta_event_getmsg, td_thr_event_enable
initializations.
(try_thread_db_load_1): Remove enable_thread_event_reporting call.
(disable_thread_event_reporting): Remove.
(record_thread): Adapt to thread_db_use_event removal.
(detach_thread): Remove.
(thread_db_detach): Adapt to thread_db_use_event removal.
(check_event): Remove.
(thread_db_wait): Adapt to thread events support removal.
(thread_db_mourn_inferior): Likewise.
(find_new_threads_callback): Likewise.
(find_new_threads_once): Likewise.
(thread_db_update_thread_list): Likewise.
Commit fc58fa65d4 (gdb/doc: Restructure frame command documentation)
reordered the sections in the 'Examining the Stack' chapter, but
missed updating the menu:
src/gdb/doc/gdb.texinfo:6968: warning: node next `Backtrace' in menu `Frame Filter Management' and in sectioning `Selection' differ
src/gdb/doc/gdb.texinfo:7167: warning: node prev `Selection' in menu `Frame Filter Management' and in sectioning `Backtrace' differ
src/gdb/doc/gdb.texinfo:7252: warning: node `Frame Filter Management' is next for `Frame Info' in sectioning but not in menu
src/gdb/doc/gdb.texinfo:7317: warning: node `Selection' is next for `Frame Filter Management' in menu but not in sectioning
src/gdb/doc/gdb.texinfo:7317: warning: node prev `Frame Filter Management' in menu `Backtrace' and in sectioning `Frame Info' differ
gdb/doc/ChangeLog:
2015-12-10 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Stack): Reorder menu.
It is possible to use multiple base addresses within a single address
range series, within the .debug_ranges section. The following is a
simplified example for 32-bit addresses:
.section ".debug_ranges"
.4byte 0xffffffff
.4byte BASE_1
.4byte START_OFFSET_1
.4byte END_OFFSET_1
.4byte START_OFFSET_2
.4byte END_OFFSET_2
.4byte 0xffffffff
.4byte BASE_2
.4byte START_OFFSET_3
.4byte END_OFFSET_3
.4byte 0
.4byte 0
In this example START/END 1 and 2 are relative to BASE_1, while
START/END 3 are relative to BASE_2.
Currently gdb does not correctly parse this DWARF, resulting in
corrupted address range information. This commit fixes this issue, and
adds a new test to cover this case.
In order to support testing of this feature extensions were made to the
testsuite dwarf assembler, additional functionality was added to the
.debug_line generation function, and a new function for generating the
.debug_ranges section was added.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_ranges_read): Unify and fix base address
reading code.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-ranges-base.c: New file.
* gdb.dwarf2/dw2-ranges-base.exp: New file.
* lib/dwarf.exp (namespace eval Dwarf): Add new variables to
support additional line table, and debug ranges generation.
(Dwarf::ranges): New function, generate .debug_ranges.
(Dwarf::lines): Support generating simple line table programs.
(Dwarf::assemble): Initialise new namespace variables.
This patch fixes the following failures for rl78-elf:
FAIL: gdb.base/vla-datatypes.exp: print int_vla
FAIL: gdb.base/vla-datatypes.exp: print unsigned_int_vla
FAIL: gdb.base/vla-datatypes.exp: print double_vla
FAIL: gdb.base/vla-datatypes.exp: print float_vla
FAIL: gdb.base/vla-datatypes.exp: print long_vla
FAIL: gdb.base/vla-datatypes.exp: print unsigned_long_vla
FAIL: gdb.base/vla-datatypes.exp: print char_vla
FAIL: gdb.base/vla-datatypes.exp: print short_vla
FAIL: gdb.base/vla-datatypes.exp: print unsigned_short_vla
FAIL: gdb.base/vla-datatypes.exp: print unsigned_char_vla
FAIL: gdb.base/vla-datatypes.exp: print foo_vla
FAIL: gdb.base/vla-datatypes.exp: print bar_vla
FAIL: gdb.base/vla-datatypes.exp: print vla_struct_object
FAIL: gdb.base/vla-datatypes.exp: print vla_union_object
FAIL: gdb.base/vla-ptr.exp: print td_vla
FAIL: gdb.mi/mi-vla-c99.exp: evaluate complete vla
The first failure in this bunch occurs due to printing an incorrect
result for a variable length array:
print int_vla
$1 = {-1, -1, -1, -1, -1}
The result should actually be this:
$1 = {0, 2, 4, 6, 8}
When I started examining this bug, I found that printing an
individual array element worked correctly. E.g. "print int_vla[2]"
resulted in 4 being printed. I have not looked closely to see why
this is the case.
I found that evaluation of the location expression for int_vla was
causing problems. This is the relevant DWARF entry for int_vla:
<2><15a>: Abbrev Number: 10 (DW_TAG_variable)
<15b> DW_AT_name : (indirect string, offset: 0xbf): int_vla
<15f> DW_AT_decl_file : 1
<160> DW_AT_decl_line : 35
<161> DW_AT_type : <0x393>
<165> DW_AT_location : 4 byte block: 86 7a 94 2 (DW_OP_breg22 (r22): -6; DW_OP_deref_size: 2)
I found that DW_OP_breg22 was providing a correct result.
DW_OP_deref_size was fetching the correct value from memory. However,
the value being fetched should be considered a pointer.
DW_OP_deref_size zero extends the fetched value prior to pushing
it onto the evaluation stack. (The DWARF-4 document specifies this
action; so GDB is faithfully implementing the DWARF-4 specification.)
However, zero extending the pointer is not sufficient for converting
that value to an address for rl78 and (perhaps) other architectures
which define a `pointer_to_address' method. (I suspect that m32c
would have the same problem.)
Ideally, we would perform the pointer to address conversion in
DW_OP_deref_size. We don't, however, know the type of the object
that the address refers to in DW_OP_deref_size. I can't think
of a way to infer the type at that point in the code.
Before proceeding, I should note that there are two other DWARF
operations that could be used in place of DW_OP_deref_size. One of
these is DW_OP_GNU_deref_type. Current GDB implements this operation,
but as is obvious from the name, it is non-standard DWARF. The other
operation is DW_OP_xderef_size. Even though it's part of DWARF-2
through DWARF-4 specifications, it's not presently implemented in GDB.
Present day GCC does not output dwarf expressions containing this
operation either. [Of the two, I like DW_OP_GNU_deref_type better.
Using it avoids the need to specify an "address space identifier".
(GCC, GDB, and other non-free tools all need to agree on the meanings
of these identifiers.)]
Back to the bug analysis...
The closest consumer of the DW_OP_deref_size result is the
DWARF_VALUE_MEMORY case in dwarf2_evaluate_loc_desc_full. At that
location, we do know the object type to which the address is intended
to refer. I added code to perform a pointer to address conversion at
this location. (See the patch.)
I do have some misgivings regarding this patch. As noted earlier, it
would really be better to perform the pointer to address conversion in
DW_OP_deref_size. I can't, however, think of a way to make this work.
Changing GCC to output one of the other aforementioned operations might
be preferable but, as noted earlier, these solutions have problems as
well. Long term, I think it'd be good to have something like
DW_OP_GNU_deref_type become part of the standard. If that can't or
won't happen, we'll need to implement DW_OP_xderef_size.
But until that happens, this patch will work for expressions in which
DW_OP_deref_size occurs last. It should even work for dereferences
followed by adding an offset. I don't think it'll work for more than
one dereference in the same expression.
gdb/ChangeLog:
* dwarf2loc.c (dwarf2_evaluate_loc_desc_full): Perform a pointer
to address conversion for DWARF_VALUE_MEMORY.
This change eliminates some failures on simulator targets and makes
the test run a bit quicker too - without this change, we have to wait
for timeouts.
gdb/testsuite/ChangeLog:
* gdb.base/async.exp (proc test_background): Add case
for asynchronous execution not supported.
This set of patches add support for the zero-padded hexadecimal format for
varobj's, defined as "zero-hexadecimal". We currently only support regular
non-zero-padded hexadecimal.
Talking with IDE developers, they would like to have this option that is
already available to GDB's print/x commands, in the CLI, as 'z'.
gdb/ChangeLog:
2015-12-09 Luis Machado <lgustavo@codesourcery.com>
* gdb/mi/mi-cmd-var.c (mi_parse_format): Handle new "zero-hexadecimal"
format.
* gdb/varobj.c (varobj_format_string): Add "zero-hexadecimal" entry.
(format_code): Add 'z' entry.
(varobj_set_display_format): Handle FORMAT_ZHEXADECIMAL.
* gdb/varobj.h (varobj_display_formats) <FORMAT_ZHEXADECIMAL>: New enum
field.
* NEWS: Add new note to MI changes citing the new zero-hexadecimal
format for -var-set-format.
gdb/doc/ChangeLog:
2015-12-09 Luis Machado <lgustavo@codesourcery.com>
* gdb.texinfo (GDB/MI Variable Objects): Update text to mention
-var-set-format's new zero-hexadecimal format.
gdb/testsuite/ChangeLog:
2015-12-09 Luis Machado <lgustavo@codesourcery.com>
* gdb.mi/mi-var-display.exp: Add new checks for the zero-hexadecimal
format and change test names to make them unique.
When `info float` is used on an AMD64 system, GDB prints
floating-point values of x87 registers with raw contents like
0x361a867a8e0527397ce0 or 0xc4f988454a1ddd3cfdab wrongly.
This happens due to truncation to double, after which the former
becomes 0.0, and the latter becomes negative infinity. This is caused
by failed detection of x86-64 host, which results in setting
gdb_host_{float,double,long_double}_format to zeros.
This commit fixes this misdetection, and adds a test to make sure
future commits don't introduce a regression here.
gdb/ChangeLog:
2015-12-09 Ruslan Kabatsayev <b7.10110111@gmail.com>
PR gdb/18702
* configure.host: Fix detection of x86_64 host when setting
floatformats.
gdb/testsuite/ChangeLog:
2015-12-09 Ruslan Kabatsayev <b7.10110111@gmail.com>
Pedro Alves <pedro@redhat.com>
PR gdb/18702
Add checking of floatformats setup on x86_64 hosts.
* gdb.arch/i386-float.S (main): Load bigval and smallval.
(smallval, bigval): New labels/constants.
* gdb.arch/i386-float.exp: Use with_test_prefix and test "info
float" after loading bigval and smallval.
gdb/ChangeLog:
* NEWS: Announce this enhancement and the corresponding new
option.
gdb/doc/ChangeLog:
* gdb.texinfo (Ada Mode Into): Move overloading support
description to its own node.
(Overloading support for Ada): New node.
In commit 6085d6f6, Z0 packet is disabled in aarch64 GDBserver if
the inferior is 32-bit or there may be multiple inferiors, because
Z0 packet isn't supported for arm then. Recently, Z0 packet
is supported in arm target, so we don't have such limitation in
aarch64 GDBserver, that is to say, aarch64 GDBserver can use Z0
packet in multi-arch/multi-inferior debugging when the inferior's
arch is arm.
Part of this patch is to revert 6085d6f6, and the rest of the patch
is to move some breakpoint related arm_* functions into
linux-aarch32-low.c in order to share them between arm and aarch64.
This patch is regression tested on aarch64-linux for debugging both
aarch64 programs and arm programs respectively.
gdb/gdbserver:
2015-12-07 Yao Qi <yao.qi@linaro.org>
* configure.srv: Append arm.o to srv_tgtobj for
aarch64*-*-linux* target.
* linux-aarch32-low.c (arm_abi_breakpoint): New macro. Moved
from linux-arm-low.c.
(arm_eabi_breakpoint, arm_breakpoint): Likewise.
(arm_breakpoint_len, thumb_breakpoint): Likewise.
(thumb_breakpoint_len, thumb2_breakpoint): Likewise.
(thumb2_breakpoint_len): Likewise.
(arm_is_thumb_mode, arm_breakpoint_at): Likewise.
(arm_breakpoint_kinds): Likewise.
(arm_breakpoint_kind_from_pc): Likewise.
(arm_sw_breakpoint_from_kind): Likewise.
(arm_breakpoint_kind_from_current_state): Likewise.
* linux-aarch32-low.h (arm_breakpoint_kind_from_pc): Declare.
(arm_sw_breakpoint_from_kind): Declare.
(arm_breakpoint_kind_from_current_state): Declare.
(arm_breakpoint_at): Declare.
* linux-aarch64-low.c (aarch64_sw_breakpoint_from_kind): Call
arm_sw_breakpoint_from_kind if process is 32-bit.
(aarch64_breakpoint_kind_from_pc): New function.
(aarch64_breakpoint_kind_from_current_state): New function.
(the_low_target): Initialize fields breakpoint_kind_from_pc
and breakpoint_kind_from_current_state.
* linux-arm-low.c (arm_breakpoint_kinds): Move to
linux-aarch32-low.c.
(arm_abi_breakpoint, arm_eabi_breakpoint): Likewise.
(arm_breakpoint, arm_breakpoint_len): Likewise.
(thumb_breakpoint, thumb_breakpoint_len): Likewise.
(thumb2_breakpoint, thumb2_breakpoint_len): Likewise.
(arm_is_thumb_mode): Likewise.
(arm_breakpoint_at): Likewise.
(arm_breakpoint_kind_from_pc): Likewise.
(arm_sw_breakpoint_from_kind): Likewise.
(arm_breakpoint_kind_from_current_state): Likewise.
Revert:
2015-08-04 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_supports_z_point_type): Return
0 for Z_PACKET_SW_BP if it may be used in multi-arch debugging.
* server.c (extended_protocol): Remove "static".
* server.h (extended_protocol): Declare it.
So far, trying to evaluate an expression involving a function call for
which GDB could find multiple function candidates outputs a menu so that
the user can select the one to run. For instance, with the two
following functions:
type New_Integer is new Integer;
function F (I : Integer) return Boolean;
function F (I : New_Integer) return Boolean;
Then we get the following GDB session:
(gdb) print f(1)
Multiple matches for f
[0] cancel
[1] foo.f at foo.adb:23
[2] foo.f at foo.adb.28
>
While the source location information is sufficient in order to
determine which one to select, one has to look for them in source files,
which is not convenient.
This commit tunes this menu in order to also include the list of formal
and return types (if any) in each entry. The above then becomes:
(gdb) print f(1)
Multiple matches for f
[0] cancel
[1] foo.f (integer) return boolean at foo.adb:23
[2] foo.f (foo.new_integer) return boolean at foo.adb.28
>
Since this output is more verbose than previously, this change also
introduces an option (set/show ada print-signatures) to get the original
output.
gdb/ChangeLog:
* ada-lang.c (print_signatures): New.
(ada_print_symbol_signature): New.
(user_select_syms): Add signatures to the output of candidate
symbols using ada_print_symbol_signature.
(_initialize_ada_language): Add a "set/show ada
print-signatures" boolean option.
gdb/testsuite/ChangeLog:
* gdb.ada/fun_overload_menu.exp: New testcase.
* gdb.ada/fun_overload_menu/foo.adb: New testcase.
Tested on x86_64-linux, no regression.
i386-nat.[hc] got renamed to x86-nat.[hc] a while back, but somehow
3 references to the old file name remained past the renaming. This
fixes all of them.
gdb/ChangeLog (with Mike Stump <mikestump@comcast.net>):
* Makefile.in (TAGS): Replace i386-nat.h by x86-nat.h.
* x86-nat.c: Replace remaining references to i386-nat
by reference to x86-nat instead.
Rename target_ops.arch_setup to .post_create_inferior. In the Linux
hook, continue calling the low arch setup, then also set ptrace flags.
This corrects the possibility of running without flags, demonstrated by
a new test that would fail to catch a fork before.
gdb/gdbserver/ChangeLog:
2015-12-04 Josh Stone <jistone@redhat.com>
* target.h (struct target_ops) <arch_setup>: Rename to ...
(struct target_ops) <post_create_inferior>: ... this.
(target_arch_setup): Rename to ...
(target_post_create_inferior): ... this, calling post_create_inferior.
* server.c (start_inferior): Update target_arch_setup calls to
target_post_create_inferior.
* linux-low.c (linux_low_ptrace_options): Forward declare.
(linux_arch_setup): Update its comment for general use.
(linux_post_create_inferior): New, run arch_setup and setup ptrace.
(struct linux_target_ops): Use linux_post_create_inferior.
* lynx-low.c (struct lynx_target_ops): Update arch_setup stub comment
to post_create_inferior.
* nto-low.c (struct nto_target_ops): Likewise.
* spu-low.c (struct spu_target_ops): Likewise.
* win32-low.c (struct win32_target_ops): Likewise.
gdb/testsuite/ChangeLog:
2015-12-04 Josh Stone <jistone@redhat.com>
* gdb.base/catch-fork-static.exp: New.
A duplicate include arm/arm.h was introduced, remove it.
Pushed as obvious.
gdb/gdbserver/ChangeLog:
* linux-arm-low.c: Remove duplicate arch/arm.h include.
In my remote cross testing (x86_64 host and aarch64 target), the test
gdb.base/sizeof.exp is skipped because gdb,noinferiorio is defined in
my gdbserver board file. Tests are skipped because the test checks
the expected value from the program's output, but I don't see why must
do it this way. With my patch applied, we can save the result in variable
in the program, and check the variable then. Then, the test doesn't rely
on inferiorio.
gdb/testsuite:
2015-12-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/sizeof.c: Don't include stdio.h and
../lib/unbuffer_output.c.
(main): New variable 'size' and 'value'. Remove printf and
gdb_unbuffer_output. Assign return value to size and value.
* gdb.base/sizeof.exp: Remove the checking to gdb,noinferiorio
at the beginning.
(check_sizeof): Check the result by printing variable 'size'.
(check_valueof): Check the result by printing variable 'value'.
GCC 4.1 gives the following warning:
gdb/remote.c: In function 'remote_parse_stop_reply':
gdb/remote.c:6549: warning: operation on 'p' may be undefined
on this line of code:
event->ptid = read_ptid (++p, &p);
Since p actually isn't used afterwards anyway, simply use NULL.
gdb/
* remote.c (remote_parse_stop_reply): Avoid GCC 4.1 "operation
may be undefined" warning.
Fix a couple of places where a struct thread_item was added to a
vector while the item.name field was uninitialized.
gdb/
* remote.c (remote_newthread_step): Initialize item.name.
(remote_get_threads_with_qthreadinfo): Likewise.
This patch removes too simple implementations of the breakpoint_reinsert_addr
operation.
The only reason to keep them around was to support thread events when
PTRACE_EVENT_CLONE was not present but this support has been removed in a
previous patch.
No regressions, tested on ubuntu 14.04 ARMv7 and x86.
With gdbserver-{native,extended} / { -marm -mthumb }
Also compilation was tested on aarch64, bfin, cris, crisv32,
m32r, mips, nios2, ppc, s390, sparc, tic6x, tile, xtensa.
gdb/gdbserver/ChangeLog:
* linux-arm-low.c (arm_reinsert_addr): Remove function.
(struct linux_target_ops <breakpoint_reinsert_addr>: Set to NULL.
* linux-cris-low.c (cris_reinsert_addr> Remove function.
(struct linux_target_ops) <breakpoint_reinsert_addr>: Set to NULL.
* linux-crisv32-low.c (cris_reinsert_addr): Remove function.
(struct linux_target_ops) <breakpoint_reinsert_addr>: Set to NULL.
* linux-mips-low.c (mips_reinsert_addr): Remove function.
(struct linux_target_ops) <breakpoint_reinsert_addr>: Set to NULL.
* linux-nios2-low.c (nios2_reinsert_addr): Remove function.
(struct linux_target_ops) <breakpoint_reinsert_addr>: Set to NULL.
* linux-sparc-low.c (sparc_reinsert_addr): Remove function.
(struct linux_target_ops) <breakpoint_reinsert_addr>: Set to NULL.
This patch removes support for thread events if PTRACE_EVENT_CLONE is not
supported in GDBServer.
Before, on systems that did not support PTRACE_EVENT_CLONE, both GDB and
GDBServer coordinated with libthread_db.so to insert breakpoints at magic
locations in libpthread.so, in order to break at thread creation and thread
death.
Simple software single stepping support was implemented to step over these
breakpoints in case there was no hardware single stepping support. However,
these simple software single stepping implementations were not fit for any other
use as discussed in :
https://sourceware.org/ml/gdb-patches/2015-04/msg01110.html
These too simple implementations conflict with ongoing work to make proper
implementations of software single stepping in GDBServer.
The problem is that if some implementations are correct and others are not and
only there for the thread magic breakpoint, we can't enable features based
solely software single step support since some would be broken.
To keep the incorrect implementations and allow the new proper ones at the same
time we would need to implement fallback code and it quickly becomes ugly and
confusing with multiple checks for legacy software single step or proper
software single step.
However, PTRACE_EVENT_CLONE was first introduced in Linux 2.5.46,
released in November 2002.
So I think it's reasonable to just remove support for kernels that don't support
PTRACE_EVENT_CLONE, and sidestep the libthread_db breakpoints issues entirely.
This thread on the mailling list discusses the issue :
https://sourceware.org/ml/gdb/2015-10/msg00078.html
No regressions, tested on ubuntu 14.04 ARMv7 and x86.
With gdbserver-{native,extended} / { -marm -mthumb }
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_look_up_symbols): Don't call
linux_supports_traceclone.
* linux-low.h (thread_db_init): Remove use_events argument.
* thread-db.c (thread_db_use_event): Remove global variable.
(struct thread_db) <td_thr_event_enable_p>: Remove field.
(struct thread_db) <td_create_bp>: Remove field.
(thread_db_create_event): Remove function.
(thread_db_enable_reporting): Likewise.
(find_one_thread): Don't check for thread_db_use_events.
(attach_thread): Likewise.
(thread_db_load_search): Remove td_thr_event_enable_p initialization.
(try_thread_db_load_1): Don't check for thread_db_use_events.
(thread_db_init): Remove use_events argument and thread events
handling.
(remove_thread_event_breakpoints): Remove function.
(thread_db_detach): Remove call to remove_thred_event_breakpoints.
Before this patch there was only one call: can_hardware_single_step. Its
implementation was a check on breakpoint_reinsert_addr if NULL it assumed
that the target could hardware single step.
This patch prepares for the case where this is not true anymore.
In order to improve software single stepping in GDBServer the
breakpoint_reinsert_addr operation of targets that had a very simple
software implementation used only for stepping over thread creation events
will be removed.
This will create a case where a target does not support hardware single
step and has the operation breakpoint_reinsert_addr set to NULL, thus
can_hardware_single_step needs to be implemented another way.
A new target operation supports_hardware_single_step is introduced and is
to return true if the target does support such a feature, support for the
feature is manually hardcoded.
Note that the hardware single step support was enabled as per the current
behavior, I did not check if tile for example really has ptrace singlestep
support but since the current implementation assumed it had, I kept it
that way.
No regressions on Ubuntu 14.04 on ARMv7 and x86.
With gdbserver-{native,extended} / { -marm -mthumb }
Compilation tested on: aarch64,arm,bfind,crisv32,m32r,ppc,s390,tic6x,tile,
xtensa.
Not tested : sh.
gdb/gdbserver/ChangeLog:
* linux-aarch64-low.c (aarch64_supports_hardware_single_step):
New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-arm-low.c (arm_supports_hardware_single_step): New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-bfin-low.c (bfin_supports_hardware_single_step): New function.
(struct linux_target_ops) <bfin_supports_hardware_single_step>:
Initialize.
* linux-crisv32-low.c (cris_supports_hardware_single_step):
New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-low.c (can_hardware_single_step): Use
supports_hardware_single_step.
(can_software_single_step): New function.
(start_step_over): Call can_software_single_step.
(linux_supports_hardware_single_step): New function.
(struct target_ops) <supports_software_single_step>: Initialize.
* linux-low.h (struct linux_target_ops)
<supports_hardware_single_step>: Initialize.
* linux-m32r-low.c (m32r_supports_hardware_single_step): New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-ppc-low.c (ppc_supports_hardware_single_step): New function.
(struct linux_target_ops) <supports_hardware_single_step> Initialize.
* linux-s390-low.c (s390_supports_hardware_single_step): New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-sh-low.c (sh_supports_hardware_single_step): New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-tic6x-low.c (tic6x_supports_hardware_single_step): New function.
(struct linux_target_ops) <tic6x_supports_hardware_single_step>:
Initialize.
* linux-tile-low.c (tile_supports_hardware_single_step): New function.
(struct linux_target_ops) <tile_supports_hardware_single_step>:
Initialize.
* linux-x86-low.c (x86_supports_hardware_single_step) New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-xtensa-low.c (xtensa_supports_hardware_single_step):
New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* target.h (struct target_ops): <supports_software_single_step>:
New field.
(target_supports_software_single_step): New macro.
Without this patch, when doing a software single step, with for example
a conditional breakpoint, gdbserver would wrongly avance the pc of
breakpoint_len and skips an instruction.
This is due to gdbserver assuming that it's hardware single stepping.
When it resumes from the breakpoint address it expects the trap to be
caused by ptrace and if it's rather caused by a software breakpoint
it assumes this is a permanent breakpoint and that it needs to skip
over it.
However when software single stepping, this breakpoint is legitimate as
it's the reinsert breakpoint gdbserver has put in place to break at
the next instruction. Thus gdbserver wrongly advances the pc and skips
an instruction.
This patch fixes this behavior so that gdbserver checks if it is a
reinsert breakpoint from software single stepping. If it is it won't
advance the pc. And if there's no reinsert breakpoint there we assume
then that it's a permanent breakpoint and advance the pc.
Here's a commented log of what would happen before and after the fix on
gdbserver :
/* Here there is a conditional breakpoint at 0x10428 that needs to be
stepped over. */
Need step over [LWP 11204]? yes, found breakpoint at 0x10428
...
/* e7f001f0 is a breakpoint instruction on arm
Here gdbserver writes the software breakpoint we would like to hit
*/
Writing e7f001f0 to 0x0001042c in process 11204
...
Resuming lwp 11220 (continue, signal 0, stop not expected)
pending reinsert at 0x10428
stop pc is 00010428
continue from pc 0x10428
...
/* Here gdbserver hit the software breakpoint that was in place
for the step over */
stop pc is 0001042c
pc is 0x1042c
step-over for LWP 11220.11220 executed software breakpoint
Finished step over.
Could not find fast tracepoint jump at 0x10428 in list (reinserting).
/* Here gdbserver writes back the original instruction */
Writing e50b3008 to 0x0001042c in process 11220
Step-over finished.
Need step over [LWP 11220]? No
/* Here because gdbserver assumes this is a permenant breakpoint it advances
the pc of breakpoint_len, in this case 4 bytes, so we have just skipped
the instruction that was written back here :
Writing e50b3008 to 0x0001042c in process 11220
*/
stop pc is 00010430
pc is 0x10430
Need step over [LWP 11220]? No, no breakpoint found at 0x10430
Proceeding, no step-over needed
proceed_one_lwp: lwp 11220
stop pc is 00010430
This patch fixes this situation and we get the right behavior :
Writing e50b3008 to 0x0001042c in process 11245
Hit a gdbserver breakpoint.
Hit a gdbserver breakpoint.
Step-over finished.
proceeding all threads.
Need step over [LWP 11245]? No
stop pc is 0001042c
pc is 0x1042c
Need step over [LWP 11245]? No, no breakpoint found at 0x1042c
Proceeding, no step-over needed
proceed_one_lwp: lwp 11245
stop pc is 0001042c
pc is 0x1042c
Resuming lwp 11245 (continue, signal 0, stop not expected)
stop pc is 0001042c
continue from pc 0x1042c
It also works if the value at 0x0001042c is a permanent breakpoint.
If so gdbserver will finish the step over, remove the reinserted breakpoint,
resume at that location and on the next SIGTRAP gdbserver will trigger
the advance PC condition as reinsert_breakpoint_inserted_here will be false.
I also tested this against bp-permanent.exp on arm (with a work in progress
software single step patchset) without any regressions.
It's also tested against x86 bp-permanent.exp without any regression.
So both software and hardware single step are tested.
No regressions on Ubuntu 14.04 on ARMv7 and x86.
With gdbserver-{native,extended} / { -marm -mthumb }
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_wait_1): Fix pc advance condition.
* mem-break.c (reinsert_breakpoint_inserted_here): New function.
* mem-break.h (reinsert_breakpoint_inserted_here): New declaration.
When manually stepping over a permanent breakpoint on ARM we need to fetch the
right breakpoint size based on the current instruction set used.
Since this is not encoded in the stop_pc, the instruction mode needs to be
fetched from the CPSR register.
This is done by introducing a new target operation called :
breakpoint_kind_from_current_state.
For other targets that do not need this, breakpoint_kind_from_pc is used.
No regressions, tested on ubuntu 14.04 ARMv7 and x86.
With gdbserver-{native,extended} / { -marm -mthumb }
gdb/gdbserver/ChangeLog:
* linux-arm-low.c (arm_is_thumb_mode): New function.
(arm_breakpoint_at): Use arm_is_thumb_mode.
(arm_breakpoint_kind_from_current_state): New function.
(struct linux_target_ops) <breakpoint_kind_from_current_state>:
Initialize.
* linux-low.c (linux_wait_1): Call breakpoint_kind_from_current_state.
(linux_breakpoint_kind_from_current_state): New function.
(struct target_ops <breakpoint_kind_from_current_state>: Initialize.
* linux-low.h (struct linux_target_ops)
<breakpoint_kind_from_current_state>: New field.
* target.h (struct target_ops): Likewise.
(target_breakpoint_kind_from_current_state): New macro.
When testing with "target remote" with "maint set target-non-stop on",
we regressions like this:
Running /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.threads/continue-pending-after-query.exp ...
FAIL: gdb.threads/continue-pending-after-query.exp: iter 4: continue until exit
FAIL: gdb.threads/continue-pending-after-query.exp: iter 6: continue until exit
FAIL: gdb.threads/continue-pending-after-query.exp: iter 10: continue until exit
=== gdb Summary ===
# of expected passes 28
# of unexpected failures 3
where gdb.log shows:
continue
Continuing.
Remote communication error. Target disconnected.: Connection reset by peer.
(gdb) FAIL: gdb.threads/continue-pending-after-query.exp: iter 4: continue until exit
Enabling gdb + gdbserver debug logs we see:
gdbserver: <<<< exiting linux_wait_1
gdbserver: handling possible serial event
gdbserver: Writing resume reply for LWP 11089.11089:0
gdbserver: handling possible serial event
gdbserver: GDBserver exiting
GDB: Packet received: OK
GDB: infrun: prepare_to_wait
GDB: Sending packet: $vStopped#55...Packet received: W0;process:2b51
GDB: Sending packet: $vStopped#55...Packet received: OK
GDB: infrun: target_wait (-1.0.0, status) =
GDB: infrun: -1.0.0 [Thread 0],
GDB: infrun: status->kind = no-resumed
GDB: Sending packet: $Hgp2b51.2b51#41...Remote connection closed
(gdb) FAIL: gdb.threads/continue-pending-after-query.exp: iter 1: continue until exit
Notice the "Packet received: W0;process:2b51" followed by
vStopped->OK.
That means the process exit notification was successfully sent to GDB
and GDB fetched it. That makes gdbserver exit, in
server.c:process_serial_event:
if (!extended_protocol && have_ran && !target_running ())
{
/* In non-stop, defer exiting until GDB had a chance to query
the whole vStopped list (until it gets an OK). */
if (QUEUE_is_empty (notif_event_p, notif_stop.queue))
{
/* Be transparent when GDB is connected through stdio -- no
need to spam GDB's console. */
if (!remote_connection_is_stdio ())
fprintf (stderr, "GDBserver exiting\n");
remote_close ();
exit (0);
}
}
However, GDB is still busy processing an earlier "no-resumed" event,
and sends a "Hg" packet, which errors out with "Remote connection
closed". IOW, it's not enough to wait for GDB to query the whole
vStopped list, gdbserver needs to wait until the exit event is really
processed.
The fix is to make gdbserver not disconnect until gdb does.
Tested on x86_64 Fedora, native gdbserver, remote + extended-remote +
with and without "maint set target-non-stop on".
gdb/gdbserver/ChangeLog:
2015-10-14 Pedro Alves <palves@redhat.com>
* remote-utils.c (readchar): Don't print "Got EOF" unless
debugging gdbserver.
* server.c (captured_main): Exit gdbserver if gdb disconnects when
in "target remote" mode and there are no processes left to debug.
(process_serial_event): Remove 'have_ran' static local and remove
logic that exits gdbserver in "target remote" mode.
Running killed-outside.exp in with "maint set target-non-stop on"
hangs currently. This test has the inferior process die with a
SIGKILL while stopped. gdbserver gets a SIGCHLD and reacts by
retrieveing the SIGKILL events out of waitpid. But because the
process is not resumed from GDB's perspective, the event is left
pending. When GDB resumes the process afterwards, the process is not
really resumed because it already has the event pending. But nothing
wakes up the event loop to consume the event.
Handle this in the same way nat/linux-nat.c:linux_nat_resume handles
this.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_resume): Wake up the event loop before
returning.
Say GDB wants to access the inferior process's memory. The current
remote general thread is 3, but GDB's switched to thread 2. Because
both threads are of the same process, GDB skips making the remote
thread be thread 2 as well (sending an Hg packet) before accessing
memory (remote.c:set_general_process). However, if thread 3 has
exited meanwhile, thread 3 no longer exists on the server and
gdbserver points current_thread to NULL. The result is the memory
access fails, even through the process still exists.
Fix this by making prepare_to_access memory select the thread to
access memory through.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* mem-break.c (check_gdb_bp_preconditions): Remove current_thread
check.
(set_gdb_breakpoint): If prepare_to_access_memory fails, set *ERR
to -1.
* target.c (struct thread_search): New structure.
(thread_search_callback): New function.
(prev_general_thread): New global.
(prepare_to_access_memory, done_accessing_memory): New functions.
* target.h (prepare_to_access_memory, done_accessing_memory):
Replace macros with function declarations.
Testing with "maint set target-non-stop on" causes regressions in
tests that rely on TARGET_WAITKIND_NO_RESUMED, which isn't modelled on
the RSP. In real all-stop, gdbserver detects the situation and
reporst error to GDB, and so the tests (e.g.,
gdb.threads/no-unwaited-for-left.exp) at fail quickly. But with
"maint set target-non-stop on", GDB instead hangs forever waiting for
a stop reply that never comes, and so the tests take longer to time
out.
This adds a new "N" stop reply packet that maps 1-1 to
TARGET_WAITKIND_NO_RESUMED.
gdb/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
PR 14618
* NEWS (New remote packets): Mention the N stop reply.
* remote.c (remote_protocol_features): Add "no-resumed" entry.
(remote_query_supported): Report no-resumed+ support.
(remote_parse_stop_reply): Handle 'N'.
(process_stop_reply): Handle TARGET_WAITKIND_NO_RESUMED.
(remote_wait_as): Handle 'N' / TARGET_WAITKIND_NO_RESUMED.
(_initialize_remote): Register "set/show remote
no-resumed-stop-reply" commands.
gdb/doc/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
PR 14618
* gdb.texinfo (Stop Reply Packets): Document the N stop reply.
(Remote Configuration): Add the "set/show remote
no-resumed-stop-reply" to the available settings table.
(General Query Packets): Document the "no-resumed" qSupported
feature.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
PR 14618
* linux-low.c (linux_wait_1): If the last resumed thread is gone,
report TARGET_WAITKIND_NO_RESUMED.
* remote-utils.c (prepare_resume_reply): Handle
TARGET_WAITKIND_NO_RESUMED.
* server.c (report_no_resumed): New global.
(handle_query) <qSupported>: Handle "no-resumed+". Report
"no-resumed+" support.
(resume): When the target reports TARGET_WAITKIND_NO_RESUMED, only
return error if the client doesn't support no-resumed events.
(push_stop_notification): New function.
(handle_target_event): Use it. Report TARGET_WAITKIND_NO_RESUMED
events if the client supports them.
gdb/testsuite/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* gdb.threads/no-unwaited-for-left.exp: Remove setup_kfail calls.
Running the testsuite against gdbserver with "maint set target-non-stop on"
stumbled on a set of problems. See code comments for details.
This handles my concerns expressed in PR14618.
gdb/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
PR 14618
* infrun.c (handle_no_resumed): New function.
(handle_inferior_event_1) <TARGET_WAITKIND_NO_RESUMED>: Defer to
handle_no_resumed.
The range-stepping tests fail with "maint set target-non-stop on" mode
because exec_cmd_expect_vCont_count doesn't know that in non-stop
mode, vCont's reply is simply "OK".
gdb/testsuite/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* lib/range-stepping-support.exp (exec_cmd_expect_vCont_count):
Handle non-stop mode vCont replies.
killed-outside.exp regresses with "maint set target-non-stop on". The
logs show:
(gdb) continue
Continuing.
infrun: clear_proceed_status_thread (Thread 9028.9028)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: proceed: resuming Thread 9028.9028
Sending packet: $Z0,3615a03966,1#4b... Notification received: Stop:X9;process:2344
Packet received: E01
Sending packet: $Z0,3615a13970,1#47...Packet received: E01
Sending packet: $Z0,3615a14891,1#4a...Packet received: E01
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 9028.9028] at 0x4005e4
Sending packet: $vCont;c:p2344.2344#1a...Packet received: E.target not running.
Sending packet: $qXfer:threads:read::0,fff#03...Packet received: l<threads>\n</threads>\n
Sending packet: $vStopped#55...Packet received: OK
Unexpected vCont reply in non-stop mode: E.target not running.
(gdb) remote_async_inferior_event_handler
infrun: target_wait (-1.0.0, status) =
infrun: 9028.0.0 [process 9028],
infrun: status->kind = signalled, signal = GDB_SIGNAL_KILL
infrun: TARGET_WAITKIND_SIGNALLED
Program terminated with signal SIGKILL, Killed.
The program no longer exists.
infrun: stop_waiting
infrun: clear_step_over_info
infrun: stop_all_threads
remote_thread_exit_events(1)
Note the "Unexpected vCont reply" error.
I traced it to a problem in status_pending_p_callback. It resumes an
LWP when it shouldn't.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* linux-low.c (thread_still_has_status_pending_p): Don't check
vCont;t here.
(lwp_resumed): New function.
(status_pending_p_callback): Return early if the LWP is not
supposed to be resumed.
When testing with "maint set target-non-stop on", a few
threading-related tests expose an issue that requires new RSP packets.
Say there are 3 threads running, 1-3. If GDB tries to stop thread 1,
2 and 3, and then waits for their stops, but meanwhile say, thread 2
exits, GDB hangs forever waiting for a stop for thread 2 that won't
ever happen.
This patch fixes the issue by adding support for thread exit events to
the protocol. However, we don't want these always enabled, as they're
useless most of the time, and would slow down remote debugging. So I
made it so that GDB can enable/disable them, and then made gdb do that
around the cases that need it, which currently is only
infrun.c:stop_all_threads.
In turn, if we have thread exit events, then the extra "thread x
exited" traffic slows down attach-many-short-lived-threads.exp enough
that gdb has trouble keeping up with new threads that are spawned
while gdb tries to stop existing ones. To fix that I added support
for the counterpart thread created events too. Enabling those when we
try to stop threads ensures that new threads never get a chance to
themselves start new threads, killing the race.
gdb/doc/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Remote Configuration): List "set/show remote
thread-events" command in configuration table.
(Stop Reply Packets): Document "T05 create" stop
reason and 'w' stop reply.
(General Query Packets): Document QThreadEvents packet. Document
QThreadEvents qSupported feature.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* linux-low.c (handle_extended_wait): Assert that the LWP's
waitstatus is TARGET_WAITKIND_IGNORE. If GDB wants to hear about
thread create events, leave the new child's status pending.
(linux_low_filter_event): If GDB wants to hear about thread exit
events, leave the LWP marked dead and don't delete it.
(linux_wait_for_event_filtered): Don't check for thread exit.
(filter_exit_event): New function.
(linux_wait_1): Use it, when returning an exit event.
(linux_resume_one_lwp_throw): Assert that the LWP's
waitstatus is TARGET_WAITKIND_IGNORE.
* remote-utils.c (prepare_resume_reply): Handle
TARGET_WAITKIND_THREAD_CREATED and TARGET_WAITKIND_THREAD_EXITED.
* server.c (report_thread_events): New global.
(handle_general_set): Handle QThreadEvents.
(handle_query) <qSupported>: Handle and report QThreadEvents+;
(handle_target_event): Handle TARGET_WAITKIND_THREAD_CREATED and
TARGET_WAITKIND_THREAD_EXITED.
* server.h (report_thread_events): Declare.
gdb/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* NEWS (New commands): Mention "set/show remote thread-events"
commands.
(New remote packets): Mention thread created/exited stop reasons
and QThreadEvents packet.
* infrun.c (disable_thread_events): New function.
(stop_all_threads): Disable/enable thread create/exit events.
Handle TARGET_WAITKIND_THREAD_EXITED.
(handle_inferior_event_1): Handle TARGET_WAITKIND_THREAD_CREATED
and TARGET_WAITKIND_THREAD_EXITED.
* remote.c (remove_child_of_pending_fork): Also remove threads of
threads that have TARGET_WAITKIND_THREAD_EXITED events.
(remote_parse_stop_reply): Handle "create" magic register. Handle
'w' stop reply.
(initialize_remote): Install remote_thread_events as
to_thread_events target hook.
(remote_thread_events): New function.
* target-delegates.c: Regenerate.
* target.c (target_thread_events): New function.
* target.h (struct target_ops) <to_thread_events>: New field.
(target_thread_events): Declare.
* target/waitstatus.c (target_waitstatus_to_string): Handle
TARGET_WAITKIND_THREAD_CREATED and TARGET_WAITKIND_THREAD_EXITED.
* target/waitstatus.h (enum target_waitkind)
<TARGET_WAITKIND_THREAD_CREATED, TARGET_WAITKIND_THREAD_EXITED):
New values.
Testing with the extended-remote board with "maint set target-non-stop
on" shows a dprintf-non-stop.exp regression. The issue is simply that
the test is expecting output that is only valid for the native target:
native:
[process 8676] #1 stopped.
remote:
[Thread 8900.8900] #1 stopped.
In order to expose this without "maint set target-non-stop on", this
restarts gdb with non-stop mode already enabled.
gdb/testsuite/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* gdb.base/dprintf-non-stop.exp: Use build_executable instead of
prepare_for_testing. Start gdb with "set non-stop on" appended to
GDBFLAGS. Lax expected stop output.
Running attach-many-short-lived-threads.exp with the extended-remote
board with "maint set target-non-stop on" times out -- the attach
never completes. Enabling infrun debug logs, we see that GDB is stuck
stopping all threads:
infrun: target_wait (-1.0.0, status) =
infrun: 1639.22213.0 [Thread 1639.22213],
infrun: status->kind = stopped, signal = GDB_SIGNAL_0
infrun: Thread 1639.22260 not executing
infrun: Thread 1639.22256 not executing
infrun: Thread 1639.22258 not executing
infrun: Thread 1639.22257 not executing
infrun: Thread 1639.22259 not executing
infrun: Thread 1639.22255 not executing
infrun: Thread 1639.22253 executing, already stopping
infrun: Thread 1639.22251 executing, already stopping
infrun: Thread 1639.22252 executing, already stopping
infrun: Thread 1639.22250 executing, already stopping
infrun: Thread 1639.22254 executing, already stopping
infrun: Thread 1639.22247 executing, already stopping
infrun: Thread 1639.22213 not executing
infrun: Thread 1639.22207 not executing
infrun: Thread 1639.22201 not executing
infrun: Thread 1639.22219 not executing
infrun: Thread 1639.1639 not executing
** HANG HERE **
GDB is waiting for the stop replies of any of those "already stopping"
threads. Take 22253 for example. On the gdbserver logs we see:
...
resume_stop request for LWP 22253
stopping LWP 22253
Sending sigstop to lwp 22253
linux_resume done
...
and:
my_waitpid (-1, 0x40000001)
my_waitpid (-1, 0x80000001): status(3057f), 22253
LWFE: waitpid(-1, ...) returned 22253, ERRNO-OK
LLW: waitpid 22253 received Trace/breakpoint trap (stopped)
pc is 0x3615ef4ce1
HEW: Got clone event from LWP 22253, new child is LWP 22259
but from here on, we never see any other event for LWP 22253. In
particular, we never see the expected SIGSTOP (from "Sending sigstop"
above). The issue is that linux_resume_stopped_resumed_lwps never
re-resumes the 22253 after the clone event.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* linux-low.c (resume_stopped_resumed_lwps): Don't check whether
the thread's last_resume_kind was resume_stop.
With "maint set target-non-stop on", the attach tests occasionally
crash gdbserver.
Basically, gdb attaches with vAttach;PID, and then shortly after reads
the xml target description for that process, to figure out the
process' architecture. On the gdbserver side, the target description
is only filled in when the first process/thread in the thread group
reports its initial PTRACE_ATTACH SIGSTOP. So if GDB is fast enough,
it can read the target description _before_ that initial stop, and
then gdbserver dies dereferencing a NULL tdesc pointer.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_attach): In non-stop mode, wait for one stop
before returning.
There's currently no non-stop equivalent of the all-stop ^C (\003)
"packet" that GDB sends when a ctrl-c is pressed while a foreground
command is active. There's vCont;t, but that's defined to cause a
"signal 0" stop.
This fixes many tests that type ^C, when testing with extended-remote
with "maint set target-non-stop on". E.g.:
Continuing.
talk to me baby
PASS: gdb.base/interrupt.exp: process is alive
a
a
PASS: gdb.base/interrupt.exp: child process ate our char
^C
[Thread 22730.22730] #1 stopped.
0x0000003615ee6650 in __read_nocancel () at ../sysdeps/unix/syscall-template.S:81
81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
(gdb) FAIL: gdb.base/interrupt.exp: send_gdb control C
p func1 ()
gdb/
2015-11-30 Pedro Alves <palves@redhat.com>
* NEWS (New remote packets): Mention vCtrlC.
* remote.c (PACKET_vCtrlC): New enum value.
(async_remote_interrupt): Call target_interrupt instead of
target_stop.
(remote_interrupt_as): Remove 'ptid' parameter.
(remote_interrupt_ns): New function.
(remote_stop): Adjust.
(remote_interrupt): If the target is in non-stop mode, try
interrupting with vCtrlC.
(initialize_remote): Install set remote ctrl-c packet.
gdb/doc/
2015-11-30 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Bootstrapping): Add "interrupting remote targets"
anchor.
(Packets): Document vCtrlC.
gdb/gdbserver/
2015-11-30 Pedro Alves <palves@redhat.com>
* server.c (handle_v_requests): Handle vCtrlC.
Running local-watch-wrong-thread.exp with "maint set target-non-stop
on" exposes that gdb/remote.c only records whether the target stopped
for a breakpoint/watchpoint plus the watchpoint data address *for the
last reported remote event*. But in non-stop mode, we need to keep
that info per-thread, as each thread can end up with its own
last-status pending.
gdb/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* remote.c (struct remote_state) <remote_watch_data_address,
stop_reason>: Delete fields.
(struct private_thread_info) <stop_reason, watch_data_address>:
New fields.
(resume_clear_thread_private_info): New function.
(append_pending_thread_resumptions): Call it.
(remote_resume): Clear all threads' private info.
(process_stop_reply): Adjust.
(remote_wait_as): Don't reference remote_state's stop_reason
field.
(remote_stopped_by_sw_breakpoint)
(remote_stopped_by_hw_breakpoint, remote_stopped_by_watchpoint)
(remote_stopped_data_address): Adjust to refer get data from the
current thread.
This fixes a gdbserver crash when running
gdb.threads/non-ldr-exc-1.exp with "maint set target-non-stop on".
The problem is that qSymbol is called when gdbserver has
current_thread == NULL.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* gdbthread.h (find_any_thread_of_pid): Declare.
* inferiors.c (thread_of_pid, find_any_thread_of_pid): New
functions.
* server.c (handle_query): If current_thread is NULL, look for
another thread of the selected process.
When running with "maint set target-non-stop on", and in all-stop
mode, nothing is stopping all threads after attaching. vAttach in
non-stop can leave all threads running and GDB has to explicitly pause
them.
This is not visible with the native target, as in that case, attach
always stops all threads (the core re-resumes them in case of
"attach&").
In addition, it's not defined which thread manages to report the
initial attach stop, so always pick the lowest one (otherwise
multi-attach.exp regresses).
gdb/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* infcmd.c (attach_post_wait): If the target is always in non-stop
mode, and the UI is in all-stop mode, stop all threads and pick
the one with lowest number as current.
This is the first pass at implementing support for all-stop mode
running against the remote target using the non-stop variant of the
protocol.
The trickiest part here is the initial connection setup/synching. We
need to fetch all inferiors' target descriptions etc. before stopping
threads, because stop_all_threads needs to read the threads' registers
(to record each thread's stop_pc). But OTOH, the initial inferior
setup (target_post_attach, post_create_inferior, etc.), only works
correctly if the inferior is stopped... So I've split that initial
setup part from attach_command_post_wait to a separate function, and
added a "still needs setup" flag to the inferior structure. This is
similar to gdbserver/linux-low.c's handling of discovering the
process's target description). Then if on connection all threads of
the remote inferior are running, when we go about stopping them, as
soon as they stop we call setup_inferior, from within
stop_all_threads.
Also, in all-stop, we need to process all the initial stop replies to
learn about all the pending signal the threads may already be stopped
for, and pick the one to report as current. This is exposed by
gdb.threads/reconnect-signal.exp.
gdb/
2015-11-30 Pedro Alves <palves@redhat.com>
* gdbthread.h (switch_to_thread_no_regs): Declare.
* infcmd.c (setup_inferior): New function, factored out from ...
(attach_command_post_wait): ... this. Rename to ...
(attach_post_wait): ... this. Replace parameter async_exec with
attach_post_wait_mode parameter. Adjust.
(enum attach_post_wait_mode): New enum.
(struct attach_command_continuation_args): Replace 'async_exec'
field with 'mode' field.
(attach_command_continuation): Adjust.
(attach_command): Add comment. Mark the inferior as needing
setup. Adjust to use enum attach_post_wait_mode.
(notice_new_inferior): Use switch_to_thread_no_regs. Adjust to
use enum attach_post_wait_mode.
* inferior.h (setup_inferior): Declare.
(struct inferior) <needs_setup>: New field.
* infrun.c (set_last_target_status): Make extern.
(stop_all_threads): Make extern. Setup inferior, if necessary.
* infrun.h (set_last_target_status, stop_all_threads): Declare.
* remote-notif.c (remote_async_get_pending_events_handler)
(handle_notification): Replace non_stop checks with
target_is_non_stop_p() checks.
* remote.c (remote_notice_new_inferior): Remove non_stop check.
(remote_update_thread_list): Replace non_stop check with
target_is_non_stop_p() check.
(print_one_stopped_thread): New function.
(process_initial_stop_replies): New 'from_tty' parameter.
"Notice" all new live inferiors after storing initial stops as
pending status in each corresponding thread. If all-stop, stop
all threads, try picking a signalled thread as current, and print
the status of that one thread. Record the last target status.
(remote_start_remote): Replace non_stop checks with
target_is_non_stop_p() checks. Don't query for the remote current
thread of use qOffsets here. Pass from_tty to
process_initial_stop_replies.
(extended_remote_attach): Replace non_stop checks with
target_is_non_stop_p() checks.
(extended_remote_post_attach): Send qOffsets here.
(remote_vcont_resume, remote_resume, remote_stop)
(remote_interrupt, remote_parse_stop_reply, remote_wait): Replace
non_stop checks with target_is_non_stop_p() checks.
(remote_async): If target is non-stop, mark/clear the pending
events token.
* thread.c (switch_to_thread_no_regs): New function.
Testing with "maint set target-non-stop on" makes mi-nonstop.exp run
with the extended-remote board. That reveals that mi-nonstop.exp is
using the wrong predicate to check for "using remote protocol".
This is not visible today because non-stop tests all fail to run with
extended-remote board, because they spawn gdb and then do "set
non-stop on". However, with that board, gdb connects to the gdbserver
from within mi_gdb_start, and changing non-stop when already connected
doesn't work. Fix that by instead enabling non-stop mode on gdb's
command line.
gdb/testsuite/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* gdb.mi/mi-nonstop.exp: Append "set non-stop on" to GDBFLAGS
instead of issuing "-gdb-set non-stop 1" after starting gdb.
Use mi_is_target_remote instead of checking "is_remote target".
* lib/gdb.exp (gdb_is_target_remote): Rename to ...
(gdb_is_target_remote_prompt): ... this, and add 'prompt_regexp'
parameter.
(gdb_is_target_remote): Reimplement.
* lib/mi-support.exp (mi_is_target_remote): New procedure.
Before commit 3a8724032abf, DEMANGLE_COMPONENT_CAST was used for both
casts and conversion operators. We now have
DEMANGLE_COMPONENT_CONVERSION for the latter.
gdb/ChangeLog:
2014-11-28 Pedro Alves <palves@redhat.com>
* cp-name-parser.y (conversion_op): Use
DEMANGLE_COMPONENT_CONVERSION instead of DEMANGLE_COMPONENT_CAST.
This patch fixes the GDB internal error on AArch64 when running
watchpoint-fork.exp
top?bt 15
internal_error (file=file@entry=0x79d558 "../../binutils-gdb/gdb/linux-nat.c", line=line@entry=4866, fmt=0x793b20 "%s: Assertion `%s' failed.")
at ../../binutils-gdb/gdb/common/errors.c:51
#1 0x0000000000495bc4 in linux_nat_thread_address_space (t=<optimized out>, ptid=<error reading variable: Cannot access memory at address 0x1302>)
at ../../binutils-gdb/gdb/linux-nat.c:4866
#2 0x00000000005db2c8 in delegate_thread_address_space (self=<optimized out>, arg1=<error reading variable: Cannot access memory at address 0x1302>)
at ../../binutils-gdb/gdb/target-delegates.c:2447
#3 0x00000000005e8c7c in target_thread_address_space (ptid=<error reading variable: Cannot access memory at address 0x1302>)
at ../../binutils-gdb/gdb/target.c:2727
#4 0x000000000054eef8 in get_thread_arch_regcache (ptid=..., gdbarch=0xad51e0) at ../../binutils-gdb/gdb/regcache.c:529
#5 0x000000000054efcc in get_thread_regcache (ptid=...) at ../../binutils-gdb/gdb/regcache.c:546
#6 0x000000000054f120 in get_thread_regcache_for_ptid (ptid=...) at ../../binutils-gdb/gdb/regcache.c:560
#7 0x00000000004a2278 in aarch64_point_is_aligned (is_watchpoint=0, addr=34168, len=2) at ../../binutils-gdb/gdb/nat/aarch64-linux-hw-point.c:122
#8 0x00000000004a2e68 in aarch64_handle_breakpoint (type=hw_execute, addr=34168, len=2, is_insert=0, state=0xae8880)
at ../../binutils-gdb/gdb/nat/aarch64-linux-hw-point.c:465
#9 0x000000000048edf0 in aarch64_linux_remove_hw_breakpoint (self=<optimized out>, gdbarch=<optimized out>, bp_tgt=<optimized out>)
at ../../binutils-gdb/gdb/aarch64-linux-nat.c:657
#10 0x00000000005da8dc in delegate_remove_hw_breakpoint (self=<optimized out>, arg1=<optimized out>, arg2=<optimized out>)
at ../../binutils-gdb/gdb/target-delegates.c:492
#11 0x0000000000536a24 in bkpt_remove_location (bl=<optimized out>) at ../../binutils-gdb/gdb/breakpoint.c:13065
#12 0x000000000053351c in remove_breakpoint_1 (bl=0xb3fe70, is=is@entry=mark_inserted) at ../../binutils-gdb/gdb/breakpoint.c:4026
#13 0x000000000053ccc0 in detach_breakpoints (ptid=...) at ../../binutils-gdb/gdb/breakpoint.c:3930
#14 0x00000000005a3ac0 in handle_inferior_event_1 (ecs=0x7ffffff048) at ../../binutils-gdb/gdb/infrun.c:5042
After the fork, GDB will physically remove the breakpoints from the child
process (in frame #14), but at that time, GDB doesn't create an inferior
yet for child, but inferior_ptid is set to child's ptid (in frame #13).
In aarch64_point_is_aligned, we'll get the regcache of current_lwp_ptid
to determine if the current process is 32-bit or 64-bit, so the inferior
can't be found, and the internal error is caused.
I don't find a better fix other than not checking alignment on removing
breakpoint.
gdb:
2015-11-27 Yao Qi <yao.qi@linaro.org>
* nat/aarch64-linux-hw-point.c (aarch64_dr_state_remove_one_point):
Don't assert on alignment.
(aarch64_handle_breakpoint): Only check alignment when IS_INSERT
is true.
Both ARM and AArch64 have defined some SIMD data types in arm_neon.h,
but we don't have a test case for passing them and returning them in
inferior call. This test also covers passing and returning
homogeneous short vector aggregate (defined by AArch64 ABI document)
in inferior call too.
gdb/testsuite:
* gdb.arch/arm-neon.exp: New.
* gdb.arch/arm-neon.c: New.
AArch64 AAPCS defined HFA (homogeneous floating-point aggregate)
and HVF (homogeneous short vector aggregate), bug GDB only handles the
former. In the AAPCS doc, both types are treated exactly the same
in terms of alignment and passing locations (on registers or stack).
This patch is to extend is_hfa to handle both HFA and HVA.
gdb:
2015-11-27 Yao Qi <yao.qi@linaro.org>
* aarch64-tdep.c (is_hfa): Rename to ...
(is_hfa_or_hva): ... this. Handle vector type. All callers
updated.
(aarch64_extract_return_value): Update debugging message.
(aarch64_store_return_value): Likewise.
(aarch64_return_in_memory): Update comments.
As defined in AArch64 AAPCS, short vectors are passed through V
registers, and its maximum alignment is 16-byte. This patch is
to reflect these rules in GDB. This patch fixes some fails in
gdb.base/gnu_vector.exp.
gdb:
2015-11-27 Yao Qi <yao.qi@linaro.org>
* aarch64-tdep.c (aarch64_type_align): For vector type, return
its length, but with the maximum of 16 bytes.
(is_hfa): Return zero for vector type.
(aarch64_push_dummy_call): Handle short vectors.
(aarch64_extract_return_value): Likewise.
(aarch64_store_return_value): Likewise.
Hi,
I see one fail on aarch64-linux testing,
FAIL: gdb.cp/annota2.exp: watch triggered on a.x (timeout)
because GDB prints two frames-invalid annotation but the test expects
only one.
next^M
^M
^Z^Zpost-prompt^M
^M
^Z^Zstarting^M
^M
^Z^Zframes-invalid^M
^M
^Z^Zframes-invalid^M
^M
Note I also see the fail on Debian-s390x-m64 too.
https://sourceware.org/ml/gdb-testers/2015-q4/msg07291.html
The test shouldn't only expect one frames-invalid annotation, because
there can be multiple times of stop/resume before the user visible
stop. Ulrich did something similar before
https://www.sourceware.org/ml/gdb-patches/2009-06/msg00118.html
This patch only changes ${frames_invalid} to \(${frames_invalid}\)*
in the regexp pattern.
The patch below fixes the fail on aarch64-linux.
gdb/testsuite:
2015-11-27 Yao Qi <yao.qi@linaro.org>
* gdb.cp/annota2.exp: Allow multiple occurrences of the
frames-invalid annotation.
Variable frames_invalid was defined, but wasn't used much. This patch
is to replace the literals in the regexp with ${frames_invalid}.
gdb/testsuite:
2015-11-27 Yao Qi <yao.qi@linaro.org>
* gdb.cp/annota2.exp: Use ${frames_invalid}.
I couldn't find a test that verified the thread name functionality, so I
created a new one.
A target board can define gdb,no_thread_names if it doesn't support thread
names and wants to skip the tests that uses them.
This test has been made with Linux in mind. Not all platforms use
pthread_setname_np to set the thread name, but some #ifdefs can be added
later in order to support other platforms.
Tested on x86-64 Ubuntu 14.04, native and remote.
gdb/testsuite/ChangeLog:
* gdb.threads/names.exp: New file.
* gdb.threads/names.c: New file.
* README: Mention gdb,no_thread_names.
This patch adds support for thread names in the remote protocol, and
updates gdb/gdbserver to use it. The information is added to the XML
description sent in response to the qXfer:threads:read packet.
gdb/ChangeLog:
* linux-nat.c (linux_nat_thread_name): Replace implementation by call
to linux_proc_tid_get_name.
* nat/linux-procfs.c (linux_proc_tid_get_name): New function,
implementation inspired by linux_nat_thread_name.
* nat/linux-procfs.h (linux_proc_tid_get_name): New declaration.
* remote.c (struct private_thread_info) <name>: New field.
(free_private_thread_info): Free name field.
(remote_thread_name): New function.
(thread_item_t) <name>: New field.
(clear_threads_listing_context): Free name field.
(start_thread): Get name xml attribute.
(thread_attributes): Add "name" attribute.
(remote_update_thread_list): Copy name field.
(init_remote_ops): Assign remote_thread_name callback.
* target.h (target_thread_name): Update comment.
* NEWS: Mention remote thread name support.
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_target_ops): Use linux_proc_tid_get_name.
* server.c (handle_qxfer_threads_worker): Refactor to include thread
name in reply.
* target.h (struct target_ops) <thread_name>: New field.
(target_thread_name): New macro.
gdb/doc/ChangeLog:
* gdb.texinfo (Thread List Format): Mention thread names.
Since this code path returns a string owned by the target (we don't know how
it's allocated, could be a static read-only string), it's safer if we return
a constant string. If, for some reasons, the caller wishes to modify the
string, it should make itself a copy.
gdb/ChangeLog:
* linux-nat.c (linux_nat_thread_name): Constify return value.
* target.h (struct target_ops) <to_thread_name>: Likewise.
(target_thread_name): Likewise.
* target.c (target_thread_name): Likewise.
* target-delegates.c (debug_thread_name): Regenerate.
* python/py-infthread.c (thpy_get_name): Constify local variables.
* thread.c (print_thread_info): Likewise.
(thread_find_command): Likewise.
If GDB has been configured without libipt support, i.e. HAVE_LIBIPT is
undefined, and is running on a system that supports Intel(R) Processor Trace,
GDB will run into an internal error when trying to decode the trace.
(gdb) record btrace
(gdb) s
usage (name=0x7fffffffe954 "fib-64")
at src/fib.c:12
12 fprintf(stderr, "usage: %s <num>\n", name);
(gdb) info record
Active record target: record-btrace
Recording format: Intel(R) Processor Trace.
Buffer size: 16kB.
gdb/btrace.c:971: internal-error: Unexpected branch trace format.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This requires a system with Linux kernel 4.1 or later running on a 5th
Generation Intel Core processor or later.
The issue is documented as PR 19297.
When trying to enable branch tracing, in addition to checking the target
support for the requested branch tracing format, also check whether GDB
supports. it.
gdb/
* btrace.c (btrace_enable): Check whether HAVE_LIBIPT is defined.
testsuite/
* lib/gdb.exp (skip_btrace_pt_tests): Check for a "GDB does not
support" error.
gdb/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
* NEWS: Mention that a few "info" commands now list the
corresponding items in ascending ID order.
Before:
(gdb) info display
Auto-display expressions now in effect:
Num Enb Expression
3: y 1
2: y 1
1: y 1
After:
(gdb) info display
Auto-display expressions now in effect:
Num Enb Expression
1: y 1
2: y 1
3: y 1
gdb/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* printcmd.c (display_command): Append new display at the end of
the list.
gdb/testsuite/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* gdb.base/display.exp: Expect displays to be sorted in ascending
order. Use multi_line.
* gdb.base/solib-display.exp: Likewise.
Before:
(gdb) info checkpoints
3 process 29132 at 0x4008ad, file foo.c, line 81
2 process 29131 at 0x4008ad, file foo.c, line 81
1 process 29130 at 0x4008ad, file foo.c, line 81
* 0 Thread 0x7ffff7fc5740 (LWP 29128) (main process) at 0x4008ad, file foo.c, line 81
After:
(gdb) info checkpoints
* 0 Thread 0x7ffff7fc5740 (LWP 29128) (main process) at 0x4008ad, file foo.c, line 81
1 process 29130 at 0x4008ad, file foo.c, line 81
2 process 29131 at 0x4008ad, file foo.c, line 81
3 process 29132 at 0x4008ad, file foo.c, line 81
gdb/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* printcmd.c (display_command): Append new display at the end of
the list.
gdb/testsuite/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* gdb.base/display.exp: Expect displays to be sorted in ascending
order. Use multi_line.
* gdb.base/solib-display.exp: Likewise.
Before:
(gdb) info threads
Id Target Id Frame
3 Thread 0x7ffff77c3700 (LWP 29035) callme () at foo.c:30
2 Thread 0x7ffff7fc4700 (LWP 29034) 0x000000000040087b in child_function_2 (arg=0x0) at foo.c:60
* 1 Thread 0x7ffff7fc5740 (LWP 29030) 0x0000003b37209237 in pthread_join (threadid=140737353893632, thread_return=0x0) at pthread_join.c:92
After:
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7ffff7fc5740 (LWP 29030) 0x0000003b37209237 in pthread_join (threadid=140737353893632, thread_return=0x0) at pthread_join.c:92
2 Thread 0x7ffff7fc4700 (LWP 29034) 0x000000000040087b in child_function_2 (arg=0x0) at foo.c:60
3 Thread 0x7ffff77c3700 (LWP 29035) callme () at foo.c:30
gdb/doc/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* gdb.texinfo (Inferiors and Programs): Adjust "maint info
program-spaces" example to ascending order listing.
(Threads): Adjust "info threads" example to ascending order
listing.
(Forks): Adjust "info inferiors" example to ascending order
listing.
gdb/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* inferior.c (add_inferior_silent): Append the new inferior to the
end of the list.
* progspace.c (add_program_space): Append the new pspace to the
end of the list.
* thread.c (new_thread): Append the new thread to the end of the
list.
gdb/testsuite/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* gdb.base/foll-exec-mode.exp: Adjust to GDB listing inferiors and
threads in ascending order.
* gdb.base/foll-fork.exp: Likewise.
* gdb.base/foll-vfork.exp: Likewise.
* gdb.base/multi-forks.exp: Likewise.
* gdb.mi/mi-nonstop.exp: Likewise.
* gdb.mi/mi-nsintrall.exp: Likewise.
* gdb.multi/base.exp: Likewise.
* gdb.multi/multi-arch.exp: Likewise.
* gdb.python/py-inferior.exp: Likewise.
* gdb.threads/break-while-running.exp: Likewise.
* gdb.threads/execl.exp: Likewise.
* gdb.threads/gcore-thread.exp: Likewise.
* gdb.threads/info-threads-cur-sal.exp: Likewise.
* gdb.threads/kill.exp: Likewise.
* gdb.threads/linux-dp.exp: Likewise.
* gdb.threads/multiple-step-overs.exp: Likewise.
* gdb.threads/next-bp-other-thread.exp: Likewise.
* gdb.threads/step-bg-decr-pc-switch-thread.exp: Likewise.
* gdb.threads/step-over-lands-on-breakpoint.exp: Likewise.
* gdb.threads/step-over-trips-on-watchpoint.exp: Likewise.
* gdb.threads/thread-find.exp: Likewise.
* gdb.threads/tls.exp: Likewise.
* lib/mi-support.exp (mi_reverse_list): Delete.
(mi_check_thread_states): No longer reverse list.
... like the kernel does.
gcore-thread.exp has a check to make sure the signalled thread is the
current thread after loading the core back, but that just works by
accident, because the signalled thread happened to be the last thread
on the thread list, and gdb currently iterates over threads in reverse
order.
So this fixes gcore-thread.exp once we start walking threads in
ascending number.
gdb/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
* linux-tdep.c (find_stop_signal): Delete.
(struct linux_corefile_thread_data) <pid>: Remove field.
(linux_corefile_thread_callback): Rename to ...
(linux_corefile_thread): ... this. Now takes a struct
linux_corefile_thread_data pointer rather than a void pointer.
Remove thread state and thread pid checks.
(linux_make_corefile_notes): Prefer dumping the signalled thread
first. Use ALL_NON_EXITED_THREADS instead of
iterate_over_threads.
When trying to save fast tracepoints to file, gdb returns internal failure:
gdb/breakpoint.c:13446: internal-error: unhandled tracepoint type 27
A problem internal to GDB has been detected, further debugging may prove unreliable.
And no file including the fast tracepoints definition is created.
The patch also extends save-trace.exp to test saving tracepoint with a
fast tracepoint in there. Note that because this test doesn't actually
inserts the tracepoints in the program, we can run it with targets that
don't actually support fast tracepoints (or tracepoints at all).
gdb/ChangeLog:
* breakpoint.c (tracepoint_print_recreate): Fix logic error
if -> else if.
gdb/testsuite/ChangeLog:
* gdb.trace/actions.c: Include trace-common.h.
(main): Add a location for a fast tracepoint.
* gdb.trace/save-trace.exp: Set a fast tracepoint in addition to
the normal tracepoints.
(gdb_verify_tracepoints): Adjust number of expected tracepoints.
Some code is duplicated, to run the test twice with absolute and
relative paths, so I factored it out in a few procs. It uses
with_test_prefix to differentiate between test runs.
I replaced usages of "save-tracepoints" with "save tracepoint", since
the former is deprecated.
I also removed the "10.x", as it doesn't make much sense anymore. It
isn't used in general in the testsuite, and I don't think it's really
useful.
gdb/testsuite/ChangeLog:
* save-trace.exp: Factor out code to these...
(gdb_save_tracepoints): New.
(gdb_load_tracepoints): New.
(do_save_load_test): New.
The comment for the code in question says:
/* If the minimal symbol has a zero size, save it
but keep scanning backwards looking for one with
a non-zero size. A zero size may mean that the
symbol isn't an object or function (e.g. a
label), or it may just mean that the size was not
specified. */
As written, the code in question will only scan past the first symbol
of zero size. My change fixes the implementation to match the
comment.
Having this correct is important when the compiler generates several
local labels that are left in place by the linker. (I've been told
that the linker should eliminate these symbols, but I know of one
architecture for which this is not happening.)
I've created a test case called asmlabel.c. It's pretty simple:
main (int argc, char **argv)
{
asm ("L0:");
v = 0;
asm ("L1:");
v = 1; /* set L1 breakpoint here */
asm ("L2:");
v = 2; /* set L2 breakpoint here */
return 0;
}
If breakpoints are placed on the lines indicated by the comments,
this is the behavior of GDB built without my patch:
(gdb) continue
Continuing.
Breakpoint 2, L1 () at asmlabel.c:26
26 v = 1; /* set L1 breakpoint here */
Note that L1 appears as the function instead of main. This is not
what we want to happen. With my patch in place, we see the desired
behavior instead:
(gdb) continue
Continuing.
Breakpoint 2, main (argc=1, argv=0x7fffffffdb88) at asmlabel.c:26
26 v = 1; /* set L1 breakpoint here */
gdb/ChangeLog:
* minsyms.c (lookup_minimal_symbol_by_pc_section_1): Scan backwards
over all zero-sized symbols.
gdb/testsuite/ChangeLog:
* gdb.base/asmlabel.exp: New test.
* gdb.base/asmlabel.c: New test case.
One of our users reported an internal error using the "bt full"
command. In their situation, reproducing involved the following
scenario:
(gdb) frame 1
(gdb) bt full
#0 0xf7783430 in __kernel_vsyscall ()
No symbol table info available.
#1 0xf5550aeb in waitpid () at ../sysdeps/unix/syscall-template.S:81
No locals.
[...]
#6 0x0fe83139 in xxxx (arg=...)
[...some locals printed, and then...]
<S17b> =
[...]/dwarf2loc.c:364: internal-error: dwarf_expr_frame_base: Assertion
`framefunc != NULL' failed.
As shown above, the error happens while GDB is trying to print the value
of <S17b>, which is a local string internally generated by the compiler.
For that, it finds that the array lives in memory, and therefore tries
to create a struct value for it via:
case DWARF_VALUE_MEMORY:
{
CORE_ADDR address = dwarf_expr_fetch_address (ctx, 0);
[...]
retval = value_at_lazy (type, address + byte_offset);
Unfortunately for us, TYPE happens to be an array whose bounds
are dynamic. More precisely, the bounds of our arrays are described
in the debugging info as being...
<4><2c1985e>: Abbrev Number: 33 (DW_TAG_subrange_type)
<2c1985f> DW_AT_type : <0x2c1989c>
<2c19863> DW_AT_lower_bound : <0x2c19835>
<2c19867> DW_AT_upper_bound : <0x2c19841>
... which are references to a pair of local variables. For instance,
the lower bound is a reference to the following DIE
<3><2c19835>: Abbrev Number: 32 (DW_TAG_variable)
<2c19836> DW_AT_name : [...]
<2c1983a> DW_AT_type : <0x2c198b4>
<2c1983e> DW_AT_artificial : 1
<2c1983e> DW_AT_location : 2 byte block: 91 58 (DW_OP_fbreg: -40)
As a result of the above, value_at_lazy indirectly triggers
a resolution of TYPE (via value_from_contents_and_address),
which means a resolution of TYPE's bounds, and as seen in
the DW_AT_location attribute above for our bounds, computing
the bound's location requires the frame (its location expression
uses DW_OP_fbreg).
Unfortunately for us, value_at_lazy does not get passed a frame,
we've lost the relevant frame when we try to resolve the array's
bounds. Instead, resolve_dynamic_range gets calls dwarf2_evaluate_property
with NULL as the frame:
static struct type *
resolve_dynamic_range (struct type *dyn_range_type,
struct property_addr_info *addr_stack)
{
[...]
if (dwarf2_evaluate_property (prop, NULL, addr_stack, &value))
^^^^
... which then handles this by using the selected frame instead:
if (frame == NULL && has_stack_frames ())
frame = get_selected_frame (NULL);
In our case, the selected frame happens to be frame #1, which is
a frame where we have a minimal amount of debugging info, and in
particular, no debug info for the function itself. And because of that,
when we try to determine the frame's base...
static void
dwarf_expr_frame_base (void *baton, const gdb_byte **start,
size_t * length)
{
struct dwarf_expr_baton *debaton = (struct dwarf_expr_baton *) baton;
const struct block *bl = get_frame_block (debaton->frame, NULL);
[...]
framefunc = block_linkage_function (bl);
... framefunc ends up being NULL, which triggers the assert
in that same function:
gdb_assert (framefunc != NULL);
This patches avoids the issue by temporarily setting the selected_frame
before printing the locals of each frames.
This patch also adds a small testcase, which reproduces the same
issue, but with a slightly different outcome:
(gdb) bt full
#0 0x000000000040049a in opaque_routine ()
No symbol table info available.
#1 0x0000000000400532 in main () at wrong_frame_bt_full-main.c:20
my_table_size = 3
my_table = <error reading variable my_table (frame address is not available.)>
With this patch, the output becomes:
(gdb) bt full
[...]
my_table = {0, 1, 2}
gdb/ChangeLog:
* stack.c (print_frame_local_vars): Temporarily set the selected
frame to FRAME while printing the frame's local variables.
gdb/testsuite/ChangeLog:
* gdb.base/wrong_frame_bt_full-main.c: New file.
* gdb.base/wrong_frame_bt_full-opaque.c: New file.
* gdb.base/wrong_frame_bt_full.exp: New file.
This crash is observable by debugging a threaded program on LynxOS.
On the GDB side, this is what we would see:
% gdb q
(gdb) target remote machine:4444
(gdb) break q.adb:6
(gdb) cont
[gdb hits breakpoint]
(gdb) cont
Remote connection closed <<<--- expected: [Inferior 1 (Remote target) exited normally]
On the gdbserver side, which was launched as usual:
% gdbserver --once :4444 q
Segmentation fault (core dumped)
Ooops!
The problem happens while GDB is trying to handle the thread termination
event of the thread that hit the breakpoint. It started happening after
the following change was made:
commit 96e7a1eb6d
Date: Fri Oct 16 11:08:38 2015 -0400
Subject: gdbserver: Reset current_thread when the thread is removed.
Reset current_thread and make sure 'remove_process' is used
after all associated threads have been removed first.
More precisely:
. GDBserver receives the execution-resume order;
. lynx-low resumes it succesfully, and then relies on lynx_wait_1
to wait for the next event;
. We quickly receive one, which lynx_wait_1 analyzes to be
a "thread exit" event, and therefore does...
case SIGTHREADEXIT:
remove_thread (find_thread_ptid (new_ptid));
lynx_continue (new_ptid);
goto retry;
=> remove_thread causes current_thread to be set to NULL...
(that's the recent change mentioned above)
=> ... which causes problems during lynx_continue, because
it calls lynx_resume, which calls regcache_invalidate,
which unfortunately assumes that CURRENT_THREAD is not NULL:
void
regcache_invalidate (void)
{
/* Only update the threads of the current process. */
SEGV!--> int pid = ptid_get_pid (current_thread->entry.id);
find_inferior (&all_threads, regcache_invalidate_one, &pid);
}
Since the problem at hand is caused by trying to figure out which
inferior to reset the regcache for, and since lynx_resume actually
had that info, this patch fixes the problem by introducing a new
routine called regcache_invalidate_pid, which invalidates the cache
of the given pid; and then modifies lynx_resume use that new routine
rather than relying on regcache_invalidate to invalidate the regcache
of the expected inferior.
gdb/gdbserver/ChangeLog:
* regcache.h (regcache_invalidate_pid): Add declaration.
* regcache.c (regcache_invalidate_pid): New function, extracted
from regcache_invalidate.
(regcache_invalidate): Reimplement using regcache_invalidate_pid.
Add trivial documentation comment.
* lynx-low.c: Use regcache_invalidate_pid instead of
regcache_invalidate.
We noticed the following hang trying to run a program where one
of the subroutines we built without debugging info (opaque_routine):
$ gdb my_program
(gdb) break opaque_routine
(gdb) run
[...hangs...]
The problem comes from the fact that, at the breakpoint's address,
we have the following code:
=> 0x0000000000401994 <+4>: pop %rbp
At some point after hitting the breakpoint and stopping, GDB calls
amd64_windows_frame_decode_epilogue, which then gets stuck in the
following infinite loop:
| /* We don't care about the instruction deallocating the frame:
| if it hasn't been executed, the pc is still in the body,
| if it has been executed, the following epilog decoding will work. */
|
| /* First decode:
| - pop reg [41 58-5f] or [58-5f]. */
|
| while (1)
| {
| /* Read opcode. */
| if (target_read_memory (pc, &op, 1) != 0)
| return -1;
|
| if (op >= 0x40 && op <= 0x4f)
| {
| /* REX prefix. */
| rex = op;
|
| /* Read opcode. */
| if (target_read_memory (pc + 1, &op, 1) != 0)
| return -1;
| }
| else
| rex = 0;
|
| if (op >= 0x58 && op <= 0x5f)
| {
| /* pop reg */
| gdb_byte reg = (op & 0x0f) | ((rex & 1) << 3);
|
| cache->prev_reg_addr[amd64_windows_w2gdb_regnum[reg]] = cur_sp;
| cur_sp += 8;
| }
| else
| break;
|
| /* Allow the user to break this loop. This shouldn't happen as the
| number of consecutive pop should be small. */
| QUIT;
| }
Nothing in that loop updates PC, and therefore, because the instruction
we stopped at is a "pop", we keep looping forever doing the same thing
over and over!
This patch fixes the issue by advancing PC to the beginning of
the next instruction if the current one is a "pop reg" instruction.
gdb/ChangeLog:
* amd64-windows-tdep.c (amd64_windows_frame_decode_epilogue):
Increment PC in while loop skipping "pop reg" instructions.
The following issue has been observed on arm-android, trying to step
over the following line of code:
Put_Line (">>> " & Integer'Image (Message (I)));
Below is a copy of the GDB transcript:
(gdb) cont
Breakpoint 1, q.dump (message=...) at q.adb:11
11 Put_Line (">>> " & Integer'Image (Message (I)));
(gdb) next
0x00016000 in system.concat_2.str_concat_2 ()
The expected behavior for the "next" command is to step over
the call to Put_Line and stop at line 12:
(gdb) next
12 I := I + 1;
What happens during the next step is that the code for line 11
above make a call to system.concat_2.str_concat_2 (to implement
the '&' string concatenation operator) before making the call
to Put_Line. While stepping, GDB stops eventually stops at the
first instruction of that function, and fails to detect that
it's a function call from where we were before, and so decides
to stop stepping.
And the reason why it fails to detect that we landed inside a function
call is because it fails to unwind from that function:
(gdb) bt
#0 0x00016000 in system.concat_2.str_concat_2 ()
#1 0x0001bc74 in ?? ()
Debugging GDB, I found that GDB decides to use the ARM unwind info
for that function, which contains the following data:
0x16000 <system__concat_2__str_concat_2>: 0x80acb0b0
Compact model index: 0
0xac pop {r4, r5, r6, r7, r8, r14}
0xb0 finish
0xb0 finish
But, in fact, using that data is wrong, in this case, because
it mentions a pop of 6 registers, and therefore hints at a frame
size of 24 bytes. The problem is that, because we're at the first
instruction of the function, the 6 registers haven't been pushed
to the stack yet. In other words, using the ARM unwind entry above,
GDB is tricked into thinking that the frame size is 24 bytes, and
that the return address (r14) is available on the stack.
One visible manifestation of this issue can been seen by looking
at the value of the stack pointer, and the frame's base address:
(gdb) p /x $sp
$2 = 0xbee427b0
(gdb) info frame
Stack level 0, frame at 0xbee427c8:
^^^^^^^^^^
||||||||||
The frame's base address should be equal to the value of the stack
pointer at entry. And you eventually get the correct frame address,
as well as the correct backtrace if you just single-step one additional
instruction, past the push:
(gdb) x /i $pc
=> 0x16000 <system__concat_2__str_concat_2>:
push {r4, r5, r6, r7, r8, lr}
(gdb) stepi
(gdb) bt
#0 0x00016004 in system.concat_2.str_concat_2 ()
#1 0x00012b6c in q.dump (message=...) at q.adb:11
#2 0x00012c3c in q () at q.adb:19
Digging further, I found that GDB tries to use the ARM unwind info
only when sure that it is relevant, as explained in the following
comment:
/* The ARM exception table does not describe unwind information
for arbitrary PC values, but is guaranteed to be correct only
at call sites. We have to decide here whether we want to use
ARM exception table information for this frame, or fall back [...]
There is one case where it decides that the info is relevant,
described in the following comment:
/* We also assume exception information is valid if we're currently
blocked in a system call. The system library is supposed to
ensure this, so that e.g. pthread cancellation works.
For that, it just parses the instruction at the address it believes
to be the point of call, and matches it against an "svc" instruction.
For instance, for a non-thumb instruction, it is at...
get_frame_pc (this_frame) - 4
... and the code checking looks like the following.
if (safe_read_memory_integer (get_frame_pc (this_frame) - 4, 4,
byte_order_for_code, &insn)
&& (insn & 0x0f000000) == 0x0f000000 /* svc */)
exc_valid = 1;
However, the reason why this doesn't work in our case is that
because we are at the first instruction of a function in the innermost
frame. That frame can't possibly be making a call, and therefore
be stuck on a system call.
What the code above ends up doing is checking the instruction
just before the start of our function, which in our case is not
even an actual instruction, but unlucky for us, happens to match
the pattern it is looking for, thus leading GDB to improperly
trust the ARM unwinding data.
gdb/ChangeLog:
* arm-tdep.c (arm_exidx_unwind_sniffer): Do not check for a frame
stuck on a system call if the given frame is the innermost frame.
See the comment added in configure.ac for more details behind
this change.
gdb/gdbserver/ChangeLog:
* configure.ac: Do not call AC_CHECK_TYPES for Elf32_auxv_t
and Elf64_auxv_t if the target is Android.
Using the gdb.ada/var_rec_arr.exp test, where the program declares
an array of variant records...
type Record_Type (I : Small_Type := 0) is record
S : String (1 .. I);
end record;
type Array_Type is array (Integer range <>) of Record_Type;
... and then a variable A1 of type Array_Type, the following command
ocassionally trigger an internal error trying to allocate more memory
than we have left:
(gdb) ptype a1(1)
[...]/utils.c:1089: internal-error: virtual memory exhausted.
A problem internal to GDB has been detected,
[...]
What happens is that recent versions of GNAT are able to generate
DWARF expressions for type Record_Type, and therefore the record's
DW_AT_byte_size is not a constant, which unfortunately breaks
an assumption made by dwarf2read.c:read_structure_type when it does:
attr = dwarf2_attr (die, DW_AT_byte_size, cu);
if (attr)
{
TYPE_LENGTH (type) = DW_UNSND (attr);
}
As a result of this, when ada_evaluate_subexp tries to create
a value_zero for a1(1) while processing the OP_FUNCALL operator
as part of evaluating the subscripting operation in no-side-effect
mode, we try to allocate a value with a bogus size, potentially
triggering the out-of-memory internal error.
This patch avoids this issue by setting the length to zero in
this case. Until we decide to start supporting dynamic type
lengths in GDB's type struct, and it's not clear yet that
this is worth the effort (see added comment), that's probably
the best we can do.
gdb/ChangeLog:
* dwarf2read.c (read_structure_type): Set the type's length
to zero if it has a DW_AT_byte_size attribute which is not
a constant.
gdb/testsuite/ChangeLog:
* testsuite/gdb.ada/var_rec_arr.exp: Add "ptype a1(1)" test.
This patch fixes a typo in target.c:read_memory_robust, where
it calls read_whatever_is_readable with the function arguments
in the wrong order. Depending on the address being read, it
can cause an xmalloc with a huge size, resulting in an assertion
failure, or just read something other than what was requested.
The problem only arises when GDB is handling an MI
"-data-read-memory-bytes" request and the initial target_read returns
an error status. Note that read_memory_robust is only called from
the MI code.
gdb/ChangeLog:
* gdb/target.c (read_memory_robust): Call
read_whatever_is_readable with arguments in the correct order.
The Linux kernel disables the FPU upon returning to userland. This
introduces spurious failures in the register preservation tests in
callfuncs.exp, since the pstate.PEF bit gets cleared after system
calls.
This patch filters out the pstate register in sparc64-*-linux-gnu
targets, so the relevant tests are no longer fooled and pass.
gdb/testsuite/ChangeLog:
2015-11-20 Jose E. Marchesi <jose.marchesi@oracle.com>
* gdb.base/callfuncs.exp (fetch_all_registers): Filter out the
pstate register when comparing registers values in
sparc64-*-linux-gnu targets to avoid spurious differences.
This patch adds a missing include that makes the test program to not
be built (--Wimplicit-function-declaration).
gdb/testsuite/ChangeLog:
2015-11-20 Jose E. Marchesi <jose.marchesi@oracle.com>
* gdb.arch/sparc-sysstep.c: Include unistd.h for getpid.
The target_process_qsupported method is called for each qSupported
feature that the common code does not recognize. The only current
implementation, for x86 Linux (x86_linux_process_qsupported), assumes
that it either is called with the "xmlRegisters=i386" feature, or that
it is isn't called at all, indicating the connected GDB predates x86
XML descriptions.
That's a bad assumption however. If GDB sends in a new/unknown (to
core gdbserver) feature after "xmlRegisters=i386", say, something like
qSupported:xmlRegisters=i386;UnknownFeature+, then when
target_process_qsupported is called for "UnknownFeature+",
x86_linux_process_qsupported clears the 'use_xml' global and calls
x86_linux_update_xmltarget, and gdbserver ends up _not_ reporting a
XML description...
This commit changes the target_process_qsupported API to instead pass
down a vector of unprocessed qSupported features in one go.
(There's an early call to target_process_qsupported(NULL) that
indicates "starting qSupported processing". There's no matching call
to mark the end of processing, though. I first fixed this by passing
(char *)-1 to indicate that, and adjusted the x86 backend to only
clear 'use_xml' when qSupported processing starts, and then only call
x86_linux_update_xmltarget() when (char *)-1 was passed. However, I
wasn't that happy with the hack and came up this alternative version.)
gdb/gdbserver/ChangeLog:
2015-11-19 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_process_qsupported): Change prototype.
Adjust.
* linux-low.h (struct linux_target_ops) <process_qsupported>:
Change prototype.
* linux-x86-low.c (x86_linux_process_qsupported): Change prototype
and adjust to loop over all features.
* server.c (handle_query) <qSupported>: Adjust to call
target_process_qsupported once, passing it a vector of unprocessed
features.
* target.h (struct target_ops) <process_qsupported>: Change
prototype.
(target_process_qsupported): Adjust.
gdbserver's target_process_qsupported is called for each feature that
the gdbserver common code does not recognize. The only current
implementation, for x86 Linux, does this:
static void
x86_linux_process_qsupported (const char *query)
{
/* Return if gdb doesn't support XML. If gdb sends "xmlRegisters="
with "i386" in qSupported query, it supports x86 XML target
descriptions. */
use_xml = 0;
if (query != NULL && startswith (query, "xmlRegisters="))
{
char *copy = xstrdup (query + 13);
char *p;
for (p = strtok (copy, ","); p != NULL; p = strtok (NULL, ","))
{
if (strcmp (p, "i386") == 0)
{
use_xml = 1;
break;
}
}
free (copy);
}
x86_linux_update_xmltarget ();
}
Notice that this clears use_xml and calls x86_linux_update_xmltarget
each time target_process_qsupported is called. So if gdb sends in any
unknown feature after "xmlRegisters=i386", like e.g.,
"xmlRegisters=i386;UnknownFeature+" gdbserver ends up not reporting a
XML description...
Work around this by having GDB send the "xmlRegisters=" feature last.
gdb/ChangeLog:
2015-11-19 Pedro Alves <palves@redhat.com>
* remote.c (remote_query_supported): Send the "xmlRegisters="
feature last.
There is this build failure when building in C++:
/home/simark/src/binutils-gdb/gdb/nat/aarch64-linux-hw-point.c: In function ‘void aarch64_linux_set_debug_regs(const aarch64_debug_reg_state*, int, int)’:
/home/simark/src/binutils-gdb/gdb/nat/aarch64-linux-hw-point.c:564:64: error: ‘count’ cannot appear in a constant-expression
iov.iov_len = (offsetof (struct user_hwdebug_state, dbg_regs[count - 1])
^
We can simplify the computation and make g++ happy at the same time by
formulating as:
size of fixed part + size of variable part
thus...
size of fixed part + count * size of one variable part element
thus...
offsetof (struct user_hwdebug_state, dbg_regs) + count * sizeof (regs.dbg_reg[0]);
gdb/ChangeLog:
* nat/aarch64-linux-hw-point.c (aarch64_linux_set_debug_regs): Change
form of iov_len computation.
Both x86_64 GNU/Linux and x86_64 mingw-w64 build cleanly with
--enable-targets=all. This enables -Werror by default in C++ mode
too, in order to let the buildbot catch C++ build regressions for us.
gdb/ChangeLog:
2015-11-19 Pedro Alves <palves@redhat.com>
* configure.ac (ERROR_ON_WARNING): Don't check whether in C++
mode.
* configure: Regenerate.
gdb/gdbserver/ChangeLog:
2015-11-19 Pedro Alves <palves@redhat.com>
* configure.ac (ERROR_ON_WARNING): Don't check whether in C++
mode.
* configure: Regenerate.
Both x86_64 GNU/Linux and x86_64 mingw-w64 build cleanly with
--enable-targets=all. Let's drop the -fpermissive hack, in order to
let the buildbot catch C++ build regressions for us.
gdb/ChangeLog:
2015-11-19 Pedro Alves <palves@redhat.com>
* build-with-cxx.m4 (GDB_AC_BUILD_WITH_CXX): Remove -fpermissive.
* configure: Regenerate.
gdb/gdbserver/ChangeLog:
2015-11-19 Pedro Alves <palves@redhat.com>
* configure: Regenerate.
Fixes:
src/gdb/breakpoint.c: In function ‘void update_watchpoint(watchpoint*, int)’:
src/gdb/breakpoint.c:2147:31: error: invalid conversion from ‘int’ to ‘target_hw_bp_type’ [-fpermissive]
base->loc->watchpoint_type = -1;
^
Seems better to rely on "address == -1 && length == -1" than on a enum
value that's not really part of the set of supposedly valid enum
values. Also, factor that out to separate functions for better
localization of the concept.
gdb/ChangeLog:
2015-11-19 Pedro Alves <palves@redhat.com>
* breakpoint.c (software_watchpoint_add_no_memory_location)
(is_no_memory_software_watchpoint): New functions.
(update_watchpoint): Use
software_watchpoint_add_memoryless_location.
(breakpoint_address_bits): Use is_no_memory_software_watchpoint.
Fixes:
src/gdb/remote.c: In function ‘void remote_unpush_target()’:
src/gdb/remote.c:4610:45: error: invalid conversion from ‘int’ to ‘strata’ [-fpermissive]
pop_all_targets_above (process_stratum - 1);
^
In file included from src/gdb/inferior.h:38:0,
from src/gdb/remote.c:25:
src/gdb/target.h:2299:13: error: initializing argument 1 of ‘void pop_all_targets_above(strata)’ [-fpermissive]
extern void pop_all_targets_above (enum strata above_stratum);
^
I used to carry a patch in the C++ branch that just did:
- pop_all_targets_above (process_stratum - 1);
+ pop_all_targets_above ((enum strata) (process_stratum - 1));
But then thought that maybe adding a routine that does exactly what we
need results in clearer code. This is the result.
gdb/ChangeLog:
2015-11-19 Pedro Alves <palves@redhat.com>
* remote.c (remote_unpush_target): Use
pop_all_targets_at_and_above instead of pop_all_targets_above.
* target.c (unpush_target_and_assert): New function, factored out
from ...
(pop_all_targets_above): ... here.
(pop_all_targets_at_and_above): New function.
* target.h (pop_all_targets_at_and_above): Declare.
The patch fixes the following errors in C++ build,
gdb/gdbserver/linux-aarch64-low.c: In function 'int emit_data_processing(uint32_t*, aarch64_opcodes, aarch64_register, aarch64_register, aarch64_operand)':
gdb/gdbserver/linux-aarch64-low.c:1071:52: error: invalid conversion from 'unsigned int' to 'aarch64_opcodes' [-fpermissive]
return emit_data_processing_reg (buf, opcode | operand_opcode, rd,
^
gdb/gdbserver:
2015-11-19 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (emit_data_processing_reg): Change opcode
type to uint32_t.
This patch moves the enum definition out of the scope of struct, and
fixes the following error.
gdb/gdbserver/linux-aarch64-low.c:681:18: error: 'OPERAND_REGISTER' was not declared in this scope
operand.type = OPERAND_REGISTER;
^
gdb/gdbserver:
2015-11-19 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (enum aarch64_operand_type): New.
(struct aarch64_operand): Move enum out.
If we constify value_cstring, we might as well constify this one.
gdb/ChangeLog:
* valops.c (value_string): Constify 'ptr' parameter.
* value.h (value_string): Constify 'ptr' parameter.
Commit 91ee7171d0 (MinGW and attribute format(printf/gnu_printf))
made common/common-defs.h depend on gnulib's substitute headers.
Turns out that that broke the gdbserver/ipa build (as the buildbots
discovered) because nothing is making sure that gnulib is built before
the ipa is.
gdb/gdbserver/ChangeLog:
2015-11-18 Pedro Alves <palves@redhat.com>
* Makefile.in (all_object_files): Add $IPA_OBJS.
Hi,
I build GDB with -fsanitize=address, and run testsuite. In
gdb.base/callfuncs.exp, I see the following error,
p t_float_values(0.0,0.0)
=================================================================
==8088==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000cb650 at pc 0x6e195c bp 0x7fff164f9770 sp 0x7fff164f9768
READ of size 16 at 0x6020000cb650 thread T0^
#0 0x6e195b in regcache_raw_write /home/yao/SourceCode/gnu/gdb/git/gdb/regcache.c:912
#1 0x6e1e52 in regcache_cooked_write /home/yao/SourceCode/gnu/gdb/git/gdb/regcache.c:945
#2 0x466d69 in pass_in_v /home/yao/SourceCode/gnu/gdb/git/gdb/aarch64-tdep.c:1101
#3 0x467512 in pass_in_v_or_stack /home/yao/SourceCode/gnu/gdb/git/gdb/aarch64-tdep.c:1196
#4 0x467d7d in aarch64_push_dummy_call /home/yao/SourceCode/gnu/gdb/git/gdb/aarch64-tdep.c:1335
The code in pass_in_v read contents from V registers (128 bit), but the
data passed through V registers can be less than 128 bit. In this case,
float is passed. So writing V registers contents into contents buff
will cause overflow. In this patch, we add an array reg[V_REGISTER_SIZE],
which is to hold the contents from V registers, and then copy useful
bits to buf.
gdb:
2015-11-18 Yao Qi <yao.qi@linaro.org>
* aarch64-tdep.c (pass_in_v): Add argument len. Add local array
reg. Callers updated.
Hi,
Some tests in gdb.threads/multiple-step-overs.exp fail on arm target
when the displaced stepping on, but they pass when displaced stepping
is off.
FAIL: gdb.threads/multiple-step-overs.exp: displaced=on: step: step
FAIL: gdb.threads/multiple-step-overs.exp: displaced=on: next: next
FAIL: gdb.threads/multiple-step-overs.exp: displaced=on: continue: continue
FAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr1: continue to sigusr1_handler
when displaced stepping is on,
Sending packet: $vCont;c#a8...infrun: infrun_async(1)^M <--- [1]
infrun: prepare_to_wait^M
infrun: target_wait (-1.0.0, status) =^M
infrun: -1.0.0 [Thread 0],^M
infrun: status->kind = ignore^M
infrun: TARGET_WAITKIND_IGNORE^M
infrun: prepare_to_wait^M
Packet received: T05swbreak:;0b:f8faffbe;0d:409ee7b6;0f:d0880000;thread:p635.636;core:0;^M
infrun: target_wait (-1.0.0, status) =^M
infrun: 1589.1590.0 [Thread 1590],^M
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP^M
infrun: TARGET_WAITKIND_STOPPED^M
infrun: stop_pc = 0x88d0^M
infrun: context switch^M
infrun: Switching context from Thread 1591 to Thread 1590^
GDB resumes the whole process (all threads) rather than the specific
thread for which GDB wants to step over the breakpoint (as shown in [1]).
That is wrong because we resume a single thread and leave others stopped
when doing a normal step over where we temporarily remove the breakpoint,
single-step, reinsert the breakpoint, is that if we let other threads run
in the period while the breakpoint is removed, then these other threads
could miss the breakpoint. Since with displaced stepping, we don't ever
remove the breakpoint, it should be fine to let other threads run. However,
there's another reason that we should not let other threads run: that is
the case where some of those threads are also stopped for a breakpoint that
itself needs to be stepped over. If we just let those threads run, then
they immediately re-trap their breakpoint again.
when displaced stepping is off, GDB behaves correctly, only resumes
the specific thread (as shown in [2]).
Sending packet: $vCont;c:p611.613#b2...infrun: infrun_async(1)^M <-- [2]
infrun: prepare_to_wait^M
infrun: target_wait (-1.0.0, status) =^M
infrun: -1.0.0 [Thread 0],^M
infrun: status->kind = ignore^M
infrun: TARGET_WAITKIND_IGNORE^M
infrun: prepare_to_wait^M
Packet received: T05swbreak:;0b:f8faffbe;0d:409e67b6;0f:48880000;thread:p611.613;core:1;^M
infrun: target_wait (-1.0.0, status) =^M
infrun: 1553.1555.0 [Thread 1555],^M
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP^M
infrun: TARGET_WAITKIND_STOPPED^M
infrun: clear_step_over_info^M
infrun: stop_pc = 0x8848
The current logic in GDB on deciding the set of threads to resume is:
/* Decide the set of threads to ask the target to resume. */
if ((step || thread_has_single_step_breakpoints_set (tp))
&& tp->control.trap_expected)
{
/* We're allowing a thread to run past a breakpoint it has
hit, by single-stepping the thread with the breakpoint
removed. In which case, we need to single-step only this
thread, and keep others stopped, as they can miss this
breakpoint if allowed to run. */
resume_ptid = inferior_ptid;
}
else
resume_ptid = internal_resume_ptid (user_step);
it doesn't handle the case correctly that GDB continue (instead of
single step) the thread for displaced stepping.
I also update the comment below to reflect the code. I remove the
"with the breakpoint removed" comment, because GDB doesn't remove
breakpoints in displaced stepping, so we don't have to worry that
other threads may miss the breakpoint.
Patch is regression tested on both x86_64-linux and arm-linux.
gdb:
2015-11-17 Yao Qi <yao.qi@linaro.org>
* infrun.c (resume): Check control.trap_expected only
when deciding the set of threads to resume.
We currently throw exceptions from signal handlers (e.g., for
Quit/ctrl-c). But throwing C++ exceptions from signal handlers is
undefined. (That doesn't restore signal masks, like siglongjmp does,
and, because asynchronous signals can arrive at any instruction, we'd
have to build _everything_ with -fasync-unwind-tables to make it
reliable.) It happens to work on x86_64 GNU/Linux at least, but it's
likely broken on other ports.
Until we stop throwing from signal handlers, use setjmp/longjmp based
exceptions in C++ mode as well.
gdb/ChangeLog:
2015-11-17 Pedro Alves <palves@redhat.com>
* common/common-exceptions.h (GDB_XCPT_SJMP, GDB_XCPT_TRY)
(GDB_XCPT_RAW_TRY, GDB_XCPT): Define.
Replace __cplusplus checks with GDB_XCPT checks throughout.
* common/common-exceptions.c: Replace __cplusplus checks with
GDB_XCPT checks throughout.
Cross building gdbserver for --host=x86_64-w64-mingw32 with gcc 4.8.4
20141219 (Fedora MinGW 4.8.4-1.fc20), I get:
src/gdb/gdbserver/tracepoint.c: In function 'cmd_qtdp':
src/gdb/gdbserver/tracepoint.c:2577:7: error: unknown conversion type character 'l' in format [-Werror=format=]
trace_debug ("Defined %stracepoint %d at 0x%s, "
^
src/gdb/gdbserver/tracepoint.c:2577:7: error: unknown conversion type character 'l' in format [-Werror=format=]
src/gdb/gdbserver/tracepoint.c:2577:7: error: too many arguments for format [-Werror=format-extra-args]
src/gdb/gdbserver/tracepoint.c: In function 'stop_tracing':
src/gdb/gdbserver/tracepoint.c:3447:7: error: unknown conversion type character 'l' in format [-Werror=format=]
trace_debug ("Stopping the trace because "
^
src/gdb/gdbserver/tracepoint.c:3447:7: error: too many arguments for format [-Werror=format-extra-args]
src/gdb/gdbserver/tracepoint.c: In function 'collect_data_at_tracepoint':
src/gdb/gdbserver/tracepoint.c:4651:3: error: unknown conversion type character 'l' in format [-Werror=format=]
trace_debug ("Making new traceframe for tracepoint %d at 0x%s, hit %" PRIu64,
^
src/gdb/gdbserver/tracepoint.c:4651:3: error: too many arguments for format [-Werror=format-extra-args]
src/gdb/gdbserver/tracepoint.c: In function 'collect_data_at_step':
src/gdb/gdbserver/tracepoint.c:4687:3: error: unknown conversion type character 'l' in format [-Werror=format=]
trace_debug ("Making new step traceframe for "
^
trace_debug is a macro that calls:
static void trace_vdebug (const char *, ...) ATTRIBUTE_PRINTF (1, 2);
The calls that fail checking use PRIu64, etc., like:
trace_debug ("Defined %stracepoint %d at 0x%s, "
"enabled %d step %" PRIu64 " pass %" PRIu64,
tpoint->type == fast_tracepoint ? "fast "
: tpoint->type == static_tracepoint ? "static " : "",
tpoint->number, paddress (tpoint->address), tpoint->enabled,
tpoint->step_count, tpoint->pass_count);
gnulib's stdio/printf module replacements may make %llu, etc. work on
mingw, instead of the MS-specific %I64u, and thus may make PRIu64
expand to %llu. However, gcc isn't aware of that, because libiberty's
ansidecl.h defines ATTRIBUTE_PRINTF as using attribute format(printf).
But, with that format, gcc checks for MS-style format strings (%I64u).
In order to have gcc expect gnu/standard formats, we need to use
gnu_printf format instead. Which version to use (printf/gnu_printf)
depends on msvcrt and mingw version, and so gnulib has a
configure-time check, and defines _GL_ATTRIBUTE_FORMAT_PRINTF
accordingly.
Since _GL_ATTRIBUTE_FORMAT_PRINTF is compatible with ATTRIBUTE_PRINTF,
the fix is simply to make use of the former.
gdb/ChangeLog:
2015-11-17 Pedro Alves <palves@redhat.com>
* common/common-defs.h (ATTRIBUTE_PRINTF): Redefine in terms of
_GL_ATTRIBUTE_FORMAT_PRINTF after including ansidecl.h.
With some toolchains, building in C++ mode stumbles on many instances
of:
In file included from ../../src/gdb/../include/splay-tree.h:43:0,
from ../../src/gdb/dcache.c:26:
build-gnulib/import/inttypes.h:61:3: error: #error "This file assumes that 'int' has exactly 32 bits. Please report your platform and compiler to <bug-gnulib@gnu.org>."
# error "This file assumes that 'int' has exactly 32 bits. Please report your platform and compiler to <bug-gnulib@gnu.org>."
^
make: *** [dcache.o] Error 1
That's:
#if !(INT_MIN == INT32_MIN && INT_MAX == INT32_MAX)
# error "This file assumes that 'int' has exactly 32 bits. Please report your platform and compiler to <bug-gnulib@gnu.org>."
#endif
I see it when cross building for --host=x86_64-w64-mingw32 using
Fedora 20's g++ (gcc version 4.8.4 20141219 (Fedora MinGW
4.8.4-1.fc20)), Simon reports seeing this on several cross compilers
too.
The issue is that on some hosts that predate C++11, when using C++ one
must define __STDC_CONSTANT_MACROS/__STDC_LIMIT_MACROS to make visible
the definitions of INTMAX_C / INTMAX_MAX etc.
This was a C99 requirement that later C++11 -- the first to define
stdint.h -- removed, and then C11 removed it as well.
https://www.gnu.org/software/gnulib/manual/html_node/stdint_002eh.html
says that gnulib's stdint.h fixes this, but because we run gnulib's
configure tests with a C compiler, gnulib determines that mingw's
stdint.h is C99-compliant, and doesn't actually replace it. Actually,
even though configuring gnulib with a C++ compiler does result in
gnulib replacing stdint.h, the resulting replacement is broken for
mingw, because it defines uintptr_t incorrectly. I sent a gnulib
patch upstream to fix that, here:
https://lists.gnu.org/archive/html/bug-gnulib/2015-11/msg00004.html
but then even with that, gnulib still stumbles on other
configured-with-C++-compiler problems.
So for now, until gnulib + C++ is fixed upstream and then gdb's copy
is updated, which may take a while, I think it's best to keep
configuring gnulib in C, and define
__STDC_LIMIT_MACROS/__STDC_CONSTANT_MACROS ourselves, just like C99
intended.
gdb/ChangeLog:
2015-11-17 Pedro Alves <palves@redhat.com>
* common/common-defs.h (__STDC_CONSTANT_MACROS)
(__STDC_LIMIT_MACROS): Define before including stdint.h.
Building in C++ errors out with:
../../src/gdb/windows-nat.c: In function 'int get_windows_debug_event(target_ops*, int, target_waitstatus*)':
../../src/gdb/windows-nat.c:1503:13: warning: invalid conversion from 'int' to 'gdb_signal' [-fpermissive]
last_sig = 1;
^
../../src/gdb/windows-nat.c:1533:43: warning: invalid conversion from 'int' to 'gdb_signal' [-fpermissive]
windows_resume (ops, minus_one_ptid, 0, 1);
^
../../src/gdb/windows-nat.c:1228:1: warning: initializing argument 4 of 'void windows_resume(target_ops*, ptid_t, int, gdb_signal)' [-fpermissive]
windows_resume (struct target_ops *ops,
^
Looking at the code, I can't figure out why we treat first chance
exceptions any different here.
AFAICS, we set last_sig to 1, and then call windows_resume passing
signal==1, so the DBG_EXCEPTION_NOT_HANDLED code path in win32_resume
is taken:
~~~
if (sig != GDB_SIGNAL_0)
{
if (current_event.dwDebugEventCode != EXCEPTION_DEBUG_EVENT)
{
OUTMSG (("Cannot continue with signal %d here.\n", sig));
}
else if (sig == last_sig)
continue_status = DBG_EXCEPTION_NOT_HANDLED;
else
OUTMSG (("Can only continue with recieved signal %d.\n", last_sig));
}
~~~
Fix this by removing this special casing. gdbserver also goes
straight to continuing with DBG_EXCEPTION_NOT_HANDLED, AFAICS.
gdb/ChangeLog:
2015-11-17 Pedro Alves <palves@redhat.com>
* windows-nat.c (handle_exception): Return 0 for first chance
exceptions.
(get_windows_debug_event): Adjust.
Building in C++ caught a buglet here:
../../../src/gdb/gdbserver/win32-low.c: In function 'void win32_resume(thread_resume*, size_t)':
../../../src/gdb/gdbserver/win32-low.c:929:11: error: invalid conversion from 'int' to 'gdb_signal' [-fpermissive]
sig = resume_info[0].sig;
^
../../../src/gdb/gdbserver/win32-low.c:934:11: error: invalid conversion from 'int' to 'gdb_signal' [-fpermissive]
sig = 0;
^
Signals in the "struct thread_resume" structure are host signals, not
gdb signals. The current code happens to work because the only
signals that the Windows port supports have the same number as the gdb
equivalent (see handle_exception for the win32 exception -> gdb signal
mapping).
gdb/gdbserver/ChangeLog:
2015-11-17 Pedro Alves <palves@redhat.com>
* win32-low.c (win32_resume): Use gdb_signal_from_host,
GDB_SIGNAL_0 and gdb_signal_to_string.
Fixes:
../../src/gdb/windows-nat.c:287:11: error: invalid conversion from 'int' to 'gdb_signal' [-fpermissive]
{-1, -1}};
^
The signal number here doesn't really matter.
gdb/ChangeLog:
2015-11-17 Pedro Alves <palves@redhat.com>
* windows-nat.c (xslate): Use GDB_SIGNAL_UNKNOWN instead of -1 as
signal number for terminator.
Fixes:
../../../src/gdb/gdbserver/win32-low.c: In function 'int win32_kill(int)':
../../../src/gdb/gdbserver/win32-low.c:823:46: error: invalid conversion from 'int' to 'target_waitkind' [-fpermissive]
struct target_waitstatus our_status = { 0 };
^
handle_output_debug_string doesn't use the parameter for anything
(it's an output parameter in the gdb version), so just remove it.
gdb/gdbserver/ChangeLog:
2015-11-17 Pedro Alves <palves@redhat.com>
* win32-low.c (handle_output_debug_string): Remove parameter.
(win32_kill): Remove our_status local and adjust call to
handle_output_debug_string.
(get_child_debug_event): Adjust call to
handle_output_debug_string.
Fixes a set of errors like:
../../src/gdb/windows-nat.c: In function 'void _initialize_loadable()':
../../src/gdb/windows-nat.c:2778:30: error: invalid conversion from 'void*' to 'BOOL (*)(DWORD) {aka int (*)(long unsigned int)}' [-fpermissive]
DebugActiveProcessStop = (void *)
^
gdb/ChangeLog:
2015-11-17 Pedro Alves <palves@redhat.com>
* windows-nat.c (AdjustTokenPrivileges_ftype)
(DebugActiveProcessStop_ftype, DebugBreakProcess_ftype)
(DebugSetProcessKillOnExit_ftype, EnumProcessModules_ftype)
(GetCurrentConsoleFont_ftype, GetModuleInformation_ftype)
(LookupPrivilegeValueA_ftype, OpenProcessToken_ftype)
(GetConsoleFontSize_ftype): New typedefs.
(AdjustTokenPrivileges, DebugActiveProcessStop)
(DebugBreakProcess, DebugSetProcessKillOnExit, EnumProcessModules)
(GetConsoleFontSize, GetCurrentConsoleFont, GetModuleInformation)
(LookupPrivilegeValueA, OpenProcessToken, GetConsoleFontSize):
Adjust.
(GetModuleFileNameEx_ftype): New typedef.
(GetModuleFileNameEx): Use it.
(_initialize_loadable): Define GPA macro and use it.
c_string_type contains values meant to be OR'ed together (even though
some bits are mutually exclusive), so it makes sense to make it an
enum flags type.
gdb/ChangeLog:
2015-11-17 Simon Marchi <simon.marchi@ericsson.com>
* c-exp.y (exp): Adjust, change enum c_string_type to
c_string_type.
(parse_string_or_char): Likewise.
* c-lang.c (charset_for_string_type): Likewise.
(classify_type): Likewise.
(c_printchar): Likewise.
(c_printstr): Likewise.
(evaluate_subexp_c): Likewise. And change cast to enum
c_string_type_values.
* c-lang.h: Include "common/enum_flags.h".
(enum c_string_type): Rename to...
(enum c_string_type_values): ...this.
(c_string_type): Define new enum flags type.
This patch fixes C++ build errors like this:
/home/pedro/gdb/mygit/cxx-convertion/src/gdb/linux-tdep.c:1126:35: error: invalid conversion from ‘int’ to ‘filterflags’ [-fpermissive]
| COREFILTER_HUGETLB_PRIVATE);
^
This is a case of enums used as bit flags. Unlike "regular" enums,
these values are supposed to be or'ed together. However, in C++, the
type of "(ENUM1 | ENUM2)" is int, and you then can't assign an int to
an enum variable without a cast. That means that this:
enum foo_flags flags = 0;
if (...)
flags |= FOO_FLAG1;
if (...)
flags |= FOO_FLAG2;
... would have to be written as:
enum foo_flags flags = (enum foo_flags) 0;
if (...)
flags = (enum foo_flags) (flags | FOO_FLAG1);
if (...)
flags = (enum foo_flags) (flags | FOO_FLAG2);
which is ... ugly. Alternatively, we'd have to use an int for the
variable's type, which isn't ideal either.
This patch instead adds an "enum flags" class. "enum flags" are
exactly the enums where the values are bits that are meant to be ORed
together.
This allows writing code like the below, while with raw enums this
would fail to compile without casts to enum type at the assignments to
'f':
enum some_flag
{
flag_val1 = 1 << 1,
flag_val2 = 1 << 2,
flag_val3 = 1 << 3,
flag_val4 = 1 << 4,
};
DEF_ENUM_FLAGS_TYPE(enum some_flag, some_flags)
some_flags f = flag_val1 | flag_val2;
f |= flag_val3;
It's also possible to assign literal zero to an enum flags variable
(meaning, no flags), dispensing either adding an awkward explicit "no
value" value to the enumeration or the cast to assignments from 0.
For example:
some_flags f = 0;
f |= flag_val3 | flag_val4;
Note that literal integers other than zero do fail to compile:
some_flags f = 1; // error
C is still supported -- DEF_ENUM_FLAGS_TYPE is just a typedef in that
case.
gdb/ChangeLog:
2015-11-17 Pedro Alves <palves@redhat.com>
* btrace.h: Include common/enum-flags.h.
(btrace_insn_flags): Define.
(struct btrace_insn) <flags>: Change type.
(btrace_function_flags): Define.
(struct btrace_function) <flags>: Change type.
(btrace_thread_flags): Define.
(struct btrace_thread_info) <flags>: Change type.
* c-exp.y (token_flags): Rename to ...
(token_flag): ... this.
(token_flags): Define.
(struct token) <flags>: Change type.
* common/enum-flags.h: New file.
* compile/compile-c-types.c (convert_qualified): Change type of
'quals' local.
* compile/compile-internal.h: Include "common/enum-flags.h".
(gcc_qualifiers_flags): Define.
* completer.c (enum reg_completer_targets): Rename to ...
(enum reg_completer_target): ... this.
(reg_completer_targets): Define.
(reg_or_group_completer_1): Change type of 'targets' parameter.
* disasm.c (do_mixed_source_and_assembly_deprecated): Change type
of 'psl_flags' local.
(do_mixed_source_and_assembly): Change type of 'psl_flags' local.
* infrun.c: Include "common/enum-flags.h".
(enum step_over_what): Rename to ...
(enum step_over_what_flag): ... this.
(step_over_what): Change type.
(start_step_over): Change type of 'step_what' local.
(thread_still_needs_step_over): Now returns a step_over_what.
Adjust.
(keep_going_pass_signal): Change type of 'step_what' local.
* linux-tdep.c: Include "common/enum-flags.h".
(enum filterflags): Rename to ...
(enum filter_flag): ... this.
(filter_flags): Define.
(dump_mapping_p): Change type of 'filterflags' parameter.
(linux_find_memory_regions_full): Change type of 'filterflags'
local.
(linux_find_memory_regions_full): Pass the address of an unsigned
int to sscanf instead of the address of an enum.
* record-btrace.c (btrace_print_lines): Change type of local
'psl_flags'.
(btrace_call_history): Replace 'flags' parameter
with 'int_flags' parameter. Adjust.
(record_btrace_call_history, record_btrace_call_history_range)
(record_btrace_call_history_from): Rename 'flags' parameter to
'int_flags'. Use record_print_flags.
* record.h: Include "common/enum-flags.h".
(record_print_flags): Define.
* source.c: Include "common/enum-flags.h".
(print_source_lines_base, print_source_lines): Change type of
flags parameter.
* symtab.h: Include "common/enum-flags.h".
(enum print_source_lines_flags): Rename to ...
(enum print_source_lines_flag): ... this.
(print_source_lines_flags): Define.
(print_source_lines): Change prototype.
Instead of adding a cast at the memory_error call, as needed for C++,
and have the reader understand the indirection, make it simple and
hardcode the generic memory error at the memory_error call site.
gdb/ChangeLog:
2015-11-17 Pedro Alves <palves@redhat.com>
* guile/scm-disasm.c (gdbscm_disasm_read_memory): Return -1 on
error instead of TARGET_XFER_E_IO.
(gdbscm_disasm_memory_error): Always pass TARGET_XFER_E_IO to
memory_error.
This patch fixes all occurences of left-shifting negative constants in C cod
which is undefined by the C standard.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (_note): Fix left shift of negative value.
* gdb.trace/trace-condition.exp: Likewise.
This patch fixes all occurences of left-shifting negative constants in C cod
which is undefined by the C standard.
gdb/ChangeLog:
* hppa-tdep.c (hppa_sign_extend, hppa_low_hppa_sign_extend)
(prologue_inst_adjust_sp, hppa_frame_cache): Fix left shift of negative
value.
* dwarf2read.c (read_subrange_type): Likewise.
Hi,
I build GDB with -fsanitize=address, and run testsuite. In
gdb.base/callfuncs.exp, I see the following error,
p/c fun1()
=================================================================^M
==9601==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffee858530 at pc 0x6df079 bp 0x7fffee8583a0 sp 0x7fffee858398
WRITE of size 16 at 0x7fffee858530 thread T0
#0 0x6df078 in regcache_raw_read /home/yao/SourceCode/gnu/gdb/git/gdb/regcache.c:673
#1 0x6dfe1e in regcache_cooked_read /home/yao/SourceCode/gnu/gdb/git/gdb/regcache.c:751
#2 0x4696a3 in aarch64_extract_return_value /home/yao/SourceCode/gnu/gdb/git/gdb/aarch64-tdep.c:1708
#3 0x46ae57 in aarch64_return_value /home/yao/SourceCode/gnu/gdb/git/gdb/aarch64-tdep.c:1918
We are extracting return value from V registers (128 bit), but only
allocate X_REGISTER_SIZE-byte array, which isn't sufficient. This
patch changes the array to V_REGISTER_SIZE.
gdb:
2015-11-16 Yao Qi <yao.qi@linaro.org>
* aarch64-tdep.c (aarch64_extract_return_value): Change array
buf's length to V_REGISTER_SIZE.
This patch changes the last argument of functions pass_in_x_or_stack,
pass_in_v_or_stack, pass_on_stack, and pass_in_x to type value *.
gdb:
2015-11-16 Yao Qi <yao.qi@linaro.org>
* aarch64-tdep.c (pass_in_x_or_stack): Change argument type
from bfd_byte * to value *. Caller updated.
(pass_in_x): Likewise.
(pass_in_v_or_stack): Likewise.
(pass_on_stack): Likewise.
Both aarch64_push_dummy_call and bfin_push_dummy_call only use args[i]
contents but then never write to them, so that we can use
value_contents instead.
gdb:
2015-11-16 Yao Qi <yao.qi@linaro.org>
* aarch64-tdep.c (aarch64_push_dummy_call): Call value_contents instead
of value_contents_writeable.
* bfin-tdep.c (bfin_push_dummy_call): Likewise.
When I build GDB with -fsanitize=address, and run testsuite,
some gdb.base/*.exp test triggers the ERROR below,
=================================================================
==7646==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000242810 at pc 0x487844 bp 0x7fffe32e84e0 sp 0x7fffe32e84d8
READ of size 4 at 0x603000242810 thread T0
#0 0x487843 in push_stack_item /home/yao/SourceCode/gnu/gdb/git/gdb/arm-tdep.c:3405
#1 0x48998a in arm_push_dummy_call /home/yao/SourceCode/gnu/gdb/git/gdb/arm-tdep.c:3960
In that path, GDB passes value on stack, in an INT_REGISTER_SIZE slot,
but the value contents' length can be less than INT_REGISTER_SIZE, so
the contents will be accessed out of the bound. This patch adds an
array buf[INT_REGISTER_SIZE], and copy val to buf before writing them
to stack.
gdb:
2015-11-16 Yao Qi <yao.qi@linaro.org>
* arm-tdep.c (arm_push_dummy_call): New array buf. Store regval
to buf. Pass buf instead of val to push_stack_item.
This patch teaches GDB to support gnu vector in inferior calls. As a
result, fails in gdb.base/gnu_vector.exp are fixed. The calling
convention of gnu vector isn't documented in the AAPCS, because it
is the GCC extension. I checked the gcc/config/arm/arm.c, understand
how GCC pass arguments and return values, and do the same in GDB side.
The patch is tested with both hard float and soft float on arm-linux.
gdb:
2015-11-13 Yao Qi <yao.qi@linaro.org>
PR tdep/19051
* arm-tdep.c (arm_type_align): Return the right alignment
value for vector.
(arm_vfp_cprc_sub_candidate): Return true for 64-bit and
128-bit vector types.
(arm_return_in_memory): Handel vector type.
Current arm_return_in_memory isn't friendly to adding new things in it.
Moreover, a lot of stuff are about APCS, which is not used nowadays (AAPCS
is being used). This patch is to refactor arm_return_in_memory, so that
some code can be shared for both APCS and AAPCS at the beginning of
arm_return_in_memory, and then each ABI (APCS and AAPCS) are processed
separately.
gdb:
2015-11-13 Yao Qi <yao.qi@linaro.org>
* arm-tdep.c (arm_return_in_memory): Rewrite it.
(arm_return_value): Call arm_return_in_memory for
TYPE_CODE_COMPLEX.
This patch removes the leftover of the d10v stuff in the testsuite
directory. The d10v port was removed in GDB 6.7, but I happen to see
that there are still some leftovers about d10v in testsuite.
gdb/testsuite:
2015-11-13 Yao Qi <yao.qi@linaro.org>
* gdb.base/call-sc.exp (test_scalar_returns): Remove the
comments about d10v.
(test_scalar_returns): Likewise.
* gdb.base/d10v.ld: Remove.
* gdb.base/overlays.exp: Remove the target triplet checking for
d10v-*-*.
* gdb.base/structs.exp (test_struct_returns): Remove the
comments about d10v.
(test_struct_calls): Likewise.
gdb.base/gnu_vector.c printf the vector and gdb.base/gnu_vector.exp
expects the output by gdb_test_multiple. Nowadays, the test doesn't
expect the output from inferior_spawn_id, which is wrong. Even we
change the test to expect from inferior_spawn_id for the inferior
output, it is still possible the inferior exit before tcl/expect gets
the inferior output. We see this fail on both s390x-linux and
ppc-linux on buildbot,
FAIL: gdb.base/gnu_vector.exp: verify vector return value (the program exited)
https://sourceware.org/ml/gdb-testers/2015-q4/msg04922.htmlhttps://sourceware.org/ml/gdb-testers/2015-q4/msg04952.html
In order to address these two shortcomings above in gnu_vector.exp,
this patch rewrites the test a little bit. Get rid of checking the
inferior output, and instead checking them by printing them. In this
way, the test can also be run on the target without inferior io
(gdb,noinferiorio is set in the board file).
gdb/testsuite:
2015-11-13 Yao Qi <yao.qi@linaro.org>
* gdb.base/gnu_vector.exp: Check the return value by "p res".
* gdb.base/gnu_vector.c: Don't include stdio.h.
(main): Don't print res and call add_some_intvecs.
The assembly code for emitting the proper tracepointable instruction
was duplicated in many places. Keep it in one place, to reduce work
needed for new targets.
gdb/testsuite/ChangeLog:
* gdb.trace/change-loc.h: include "trace-common.h", remove SYMBOL
macro.
(func5): Removed.
(func4): Use FAST_TRACEPOINT_LABEL.
* gdb.trace/ftrace-lock.c: include "trace-common.h", remove SYMBOL
macro.
(func): Removed.
(thread_function): Use FAST_TRACEPOINT_LABEL.
* gdb.trace/ftrace.c: include "trace-common.h", remove SYMBOL macro.
(func): Remove.
(marker): Use FAST_TRACEPOINT_LABEL.
* gdb.trace/pendshr1.c: include "trace-common.h", remove SYMBOL macro.
(pendfunc1): Remove.
(pendfunc): Use FAST_TRACEPOINT_LABEL.
* gdb.trace/pendshr2.c: include "trace-common.h", remove SYMBOL macro.
(foo): Remove.
(pendfunc2): Use FAST_TRACEPOINT_LABEL.
* gdb.trace/trace-break.c: include "trace-common.h", remove SYMBOL
macro.
(func): Remove.
(marker): Use FAST_TRACEPOINT_LABEL.
* gdb.trace/trace-common.h: New header.
* gdb.trace/trace-condition.c: include "trace-common.h", remove SYMBOL
macro.
(func): Remove.
(marker): Use FAST_TRACEPOINT_LABEL.
* gdb.trace/trace-mt.c: include "trace-common.h", remove SYMBOL macro.
(func): Remove.
(thread_function): Use FAST_TRACEPOINT_LABEL.
These casts uses the typedef target type (long int *) instead of the
typedef name. This was a little mistake in one of the big C++ cast
patches.
gdb/ChangeLog:
* inf-ptrace.c (inf_ptrace_fetch_register): Change long int *
cast to PTRACE_TYPE_RET *.
(inf_ptrace_store_register): Likewise.
Switch to using 'add_info' function for creating basic info
sub-commands.
gdb/ChangeLog:
* avr-tdep.c (_initialize_avr_tdep): Switch to 'add_info' for creating
info sub-commands.
* gnu-nat.c (add_task_commands): Likewise.
* macrocmd.c (_initialize_macrocmd): Likewise.
The 'add_info' function is used for creating info commands, these
commands should be created as 'class_info' rather than 'no_class'.
gdb/ChangeLog:
* cli/cli-decode.c (add_info): Switch to class_info.
These variables were used in many gdb.trace tests. Keep them in one place,
to reduce work needed for new targets.
gdb/testsuite/ChangeLog:
* gdb.trace/backtrace.exp: Use global fpreg/spreg definition, add $
in front.
* gdb.trace/change-loc.exp: Use global pcreg definition.
* gdb.trace/collection.exp: Use global pcreg/fpreg/spreg definition.
* gdb.trace/entry-values.exp: Use global spreg definition, add $
in front.
* gdb.trace/mi-trace-frame-collected.exp: Use global pcreg definition.
* gdb.trace/pending.exp: Likewise.
* gdb.trace/report.exp: Use global pcreg/fpreg/spreg definition.
* gdb.trace/trace-break.exp: Likewise.
* gdb.trace/trace-condition.exp: Use global pcreg definition, add $
in front.
* gdb.trace/unavailable.exp: Use global pcreg/fpreg/spreg definition.
* gdb.trace/while-dyn.exp: Use global fpreg definition, add $
in front.
* lib/trace-support.exp: Define fpreg, spreg, pcreg variables.
Consider a function with the following signature...
function F (R : out Rec_Type) return Enum_Type;
... where Rec_Type is a simple record:
type Rec_Type is record
Cur : Integer;
end record;
Trying to "finish" from that function causes GDB to SEGV:
(gdb) fin
Run till exit from #0 bar.f (r=...) at bar.adb:5
0x00000000004022fe in foo () at foo.adb:5
5 I : Enum_Type := F (R);
[1] 18949 segmentation fault (core dumped) /[..]/gdb
This is related to the fact that funtion F has a parameter (R)
which is an "out" parameter being passed by copy. For those,
GNAT transforms the return value to be a record with multiple
fields: The first one is called "RETVAL" and contains the return
value shown in the source, and the remaining fields have the same
name as the "out" or "in out" parameters which are passed by copy.
So, in the example above, function F returns a struct that has
one field who name is "r".
Because "RETVAL" starts with "R", GDB thinks it's a wrapper field,
because it looks like the encoding used for variant records:
-- member_name ::= {choice} | others_choice
-- choice ::= simple_choice | range_choice
-- simple_choice ::= S number
-- range_choice ::= R number T number <<<<<----- here
-- number ::= {decimal_digit} [m]
-- others_choice ::= O (upper case letter O)
See ada_is_wrapper_field:
return (name != NULL
&& (startswith (name, "PARENT")
|| strcmp (name, "REP") == 0
|| startswith (name, "_parent")
|| name[0] == 'S' || name[0] == 'R' || name[0] == 'O'));
As a result of this, when trying to print the RETURN value,
we think that RETVAL is a wrapper, and thus recurse into
print_field_values...
if (ada_is_wrapper_field (type, i))
{
comma_needed =
print_field_values (TYPE_FIELD_TYPE (type, i),
valaddr,
(offset
+ TYPE_FIELD_BITPOS (type, i) / HOST_CHAR_BIT),
stream, recurse, val, options,
comma_needed, type, offset, language);
... which is a problem since print_field_values assumes that
the type it is given ("TYPE_FIELD_TYPE (type, i)" here), is also
a record type. However, that's not the case, since RETVAL is
an enum. That eventually leads GDB to a NULL type when trying to
extract fields out of the enum, which then leads to a SEGV when
trying to dereference it.
Ideally, we'd want to be a little more careful in identifying
wrapper fields, by enhancing ada_is_wrapper_field to be a little
more complete in its analysis of the field name before declaring
it a variant record wrapper. However, it's not super easy to do
so, considering that the choices can be combined together when
complex choices are used. Eg:
-- [...] the choice 1 .. 4 | 7 | -10 would be represented by
-- R1T4S7S10m
Given that we are working towards getting rid of GNAT encodings,
which means that the above will eventually disappear, we took
the more pragmatic approach is just treating RETVAL as a special
case.
gdb/ChangeLog:
* ada-lang.c (ada_is_wrapper_field): Add special handling
for fields called "RETVAL".
gdb/testsuite/ChangeLog:
* gdb.ada/fin_fun_out: New testcase.
We've already has the definition like this,
#define ELF_STRING_ARM_unwind ".ARM.exidx"
so it is better to use the macro rather than the string.
gdb:
2015-11-09 Yao Qi <yao.qi@linaro.org>
* arm-tdep.c (arm_exidx_new_objfile): Use
ELF_STRING_ARM_unwind.
This patch adds a new function displaced_step_in_progress_thread,
which returns whether the thread is in progress of displaced
stepping.
gdb:
2015-11-09 Yao Qi <yao.qi@linaro.org>
* infrun.c (displaced_step_in_progress_thread): New function.
(handle_inferior_event_1): Call it.
Some of the source code for the test cases in the GDB testsuite
reside in .S files containing assembly code. These files typically
define a symbol - such as main - which may, depending on the target,
require a prefix such as underscore.
For example, gdb.dwarf2/dw-compdir-oldgcc.S defines the symbol main:
main: .globl main
Some targets, such as rx-elf, require main to have an underscore
prefix. (If it doesn't, a linker error results due to not being able
to find _main required by crt0.o.) So, instead, the above should look
like this for rx-elf and other targets with this same requirement:
_main: .globl _main
This patch defines a new tcl proc in lib/gdb named
gdb_target_symbol_prefix_flags_asm. This proc returns a string
which will - assuming everything else is wired up correctly - cause
-DSYMBOL_PREFIX=_ to be passed on the command line to the compiler.
The test cases are augmented with a macro definition for SYMBOL
as follows:
#define CONCAT1(a, b) CONCAT2(a, b)
#define CONCAT2(a, b) a ## b
#ifdef SYMBOL_PREFIX
# define SYMBOL(str) CONCAT1(SYMBOL_PREFIX, str)
#else
# define SYMBOL(str) str
#endif
Symbols, such as main shown in the example earlier are then wrapped
with SYMBOL like this:
SYMBOL(main): .globl SYMBOL(main)
The net effect will be to add a prefix for those targets which need
it and add no prefix for those targets which do not.
It should be noted that there was already a proc in lib/gdb.exp
called gdb_target_symbol_prefix_flags. It still exists, but has
been significantly rewritten. (There is only one small difference
between the two versions.)
That proc used to explicitly list targets which were known to
require an underscore prefix. This is no longer done; the recently
added proc, gdb_target_symbol_prefix, is now invoked to dynamically
discover whether or not a prefix is required for that particular
target.
The difference between gdb_target_symbol_prefix_flags_asm
and gdb_target_symbol_prefix_flags is that the former returns
a bare prefix while the latter returns the prefix enclosed in
double quotes. I.e. assuming that the discovered prefix is
underscore, gdb_target_symbol_prefix_flags_asm returns:
additional_flags=-DSYMBOL_PREFIX=_
while gdb_target_symbol_prefix_flags returns:
additional_flags=-DSYMBOL_PREFIX="_"
The double-quoted version is not suitable for using with .S files
containing assembly code; there is no way to strip the double quotes
using C preprocessor constructs.
It would be possible to use the bare (non double quoted) version in
C source code. However, the supporting macros become more complicated
and therefore more difficult to maintain.
gdb/testsuite/ChangeLog:
* lib/gdb (gdb_target_symbol_prefix_flags_asm): New proc.
(gdb_target_symbol_prefix_flags): Define in terms of _asm
version.
* gdb.arch/i386-float.exp, gdb.arch/i386-permbkpt.exp,
gdb.dwarf2/dw2-canonicalize-type.exp,
gdb.dwarf2/dw2-compdir-oldgcc.exp, gdb.dwarf2/dw2-minsym-in-cu.exp,
gdb.dwarf2/dw2-op-stack-value.exp, gdb.dwarf2/dw2-unresolved.exp,
gdb.dwarf2/fission-reread.exp, gdb.dwarf2/pr13961.exp: Use flags
provided by gdb_target_symbol_prefix_flags_asm.
* gdb.dwarf2/dw2-canonicalize-type.S, gdb.dwarf2/dw2-compdir-oldgcc.S,
testsuite/gdb.dwarf2/dw2-minsym-in-cu.S,
testsuite/gdb.dwarf2/dw2-unresolved-main.c,
testsuite/gdb.dwarf2/dw2-unresolved.S, gdb.dwarf2/fission-reread.S,
gdb.dwarf2/pr13961.S: Define and use SYMBOL macro (and supporting
macros where needed). Use this macro for symbols which require
the prefix provided by SYMBOL_PREFIX.
Some of the tests in gdb.dwarf2 which use Dwarf::assemble refer to
(minimal/linker) symbols created in the course of building a small
test program. Some targets use a prefix such as underscore ("_") on
these symbols. Many of the tests in gdb.dwarf2 do not take this into
account. As a consequence, these tests fail to build, resulting
either in failures or untested testcases.
Here is an example from gdb.dwarf2/dw2-regno-invalid.exp:
Dwarf::assemble $asm_file {
cu {} {
compile_unit {
{low_pc main DW_FORM_addr}
{high_pc main+0x10000 DW_FORM_addr}
} {
...
}
For targets which require an underscore prefix on linker symbols,
the two occurrences of "main" would have to have a prepended underscore,
i.e. _main instead of main.
For the above case, a call to the new proc gdb_target_symbol is used
prepend the correct prefix to the symbol. I.e. the above code is
rewritten (as shown in the patch) as follows:
Dwarf::assemble $asm_file {
cu {} {
compile_unit {
{low_pc [gdb_target_symbol main] DW_FORM_addr}
{high_pc [gdb_target_symbol main]+0x10000 DW_FORM_addr}
} {
...
}
I also found it necessary to make an adjustment to lib/dwarf.exp so that
expressions of more than just one list element can be used in DW_TAG_...
constructs. Both atomic-type.exp and dw2-bad-mips-linkage-name.exp require
this new functionality.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_target_symbol_prefix, gdb_target_symbol):
New procs.
* lib/dwarf.exp (_handle_DW_TAG): Handle attribute values,
representing expressions, of more than one list element.
* gdb.dwarf2/atomic-type.exp (Dwarf::assemble): Use gdb_target_symbol
to prepend linker symbol prefix to f.
* gdb.dwarf2/data-loc.exp (Dwarf::assemble): Likewise, for
table_1 and table_2.
* gdb.dwarf2/dw2-bad-mips-linkage-name.exp (Dwarf::assemble):
Likewise, for f and g.
* gdb.dwarf2/dw2-ifort-parameter.exp (Dwarf::assemble): Likewise,
for ptr.
* gdb.dwarf2/dw2-regno-invalid.exp (Dwarf::assemble): Likewise,
for main.
* gdb.dwarf2/dynarr-ptr.exp (Dwarf::assemble): Likewise, for
table_1_ptr and table_2_ptr.
gdb:
2015-11-05 Yao Qi <yao.qi@linaro.org>
* aarch64-tdep.c (aarch64_displaced_step_copy_insn): Call
aarch64_decode_insn and decode instruction by aarch64_inst.
This patch convert aarch64_analyze_prologue to using aarch64_decode_insn
to decode instructions. After this change, aarch64_analyze_prologue
looks much simple, and some aarch64_decode_* functions are removed
accordingly.
gdb:
2015-11-05 Yao Qi <yao.qi@linaro.org>
* aarch64-tdep.c (extract_signed_bitfield): Remove.
(decode_masked_match): Remove.
(aarch64_decode_add_sub_imm): Remove.
(aarch64_decode_br): Remove.
(aarch64_decode_eret): Remove.
(aarch64_decode_movz): Remove.
(aarch64_decode_orr_shifted_register_x): Remove.
(aarch64_decode_ret): Remove.
(aarch64_decode_stp_offset): Remove.
(aarch64_decode_stur): Remove.
(aarch64_analyze_prologue): Call aarch64_decode_insn
and use aarch64_inst to decode instructions.
This patch combines both aarch64_decode_stp_offset_wb and
aarch64_decode_stp_offset together.
gdb:
2015-11-05 Yao Qi <yao.qi@linaro.org>
* aarch64-tdep.c (aarch64_decode_stp_offset): New argument
wback.
(aarch64_decode_stp_offset_wb): Removed.
(aarch64_analyze_prologue): Don't use
aarch64_decode_stp_offset_wb.
allocate (vla1 (5)) ! vla1-not-allocated
l = allocated(vla1) ! vla1-allocated <------------------
Expecting: ^(510-data-evaluate-expression vla1[^M
]+)?(510\^done,value="\(0, 0, 0, 0, 0\)"[^M
]+[(]gdb[)] ^M
[ ]*)
510-data-evaluate-expression vla1^M
510^done,value="(1.82987403e-09, 7.8472714e-44, 1.82987403e-09, 7.8472714e-44, 2.67929926e+20)"^M
(gdb) ^M
FAIL: gdb.mi/mi-vla-fortran.exp: evaluate allocated vla
gcc-4.9.2-6.fc21.x86_64
I think some older gfortran did initialize allocated memory but that is an
unspecified behavior. I haven't found any initialization mentioned
in Fortran 90 standard (draft) and it is also clearly stated here:
https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/268786
Initialization to 0 of allocated arrays (of integers) is an
implementation issue. i.e. do not rely on it.
Joel Brobecker wrote:
I am wondering if it might be better to just relax instead the regexp to allow
any number rather than just remove the test altogether. The test allows us to
verify that, as soon as we're past the "allocate" call, we no longer say "not
allocated".
gdb/testsuite/ChangeLog
2015-11-03 Jan Kratochvil <jan.kratochvil@redhat.com>
Joel Brobecker <brobecker@adacore.com>
* gdb.mi/mi-vla-fortran.exp (evaluate allocated vla): Permit any data.
This is needed to avoid O(n**2) complexity when recording MVCLE and other
partial execution instructions.
gdb/ChangeLog:
PR/18376
* gdb/s390-linux-tdep.c (s390_is_partial_instruction): New function.
(s390_software_single_step): New function.
(s390_displaced_step_hw_singlestep): New function.
(s390_gdbarch_init): Fill gdbarch slots with the above.
gdb/ChangeLog:
PR/18376
* gdb/configure.tgt: Add linux-record.o to s390*-linux.
* gdb/s390-linux-tdep.c: #include "linux-record.h", "record-full.h"
(s390_linux_record_tdep): New static global variable.
(s390x_linux_record_tdep): New static global variable.
(s390_all_but_pc_registers_record): New function.
(s390_canonicalize_syscall): New function.
(s390_linux_syscall_record): New function.
(s390_linux_record_signal): New function.
(s390_record_calc_disp_common): New function.
(s390_record_calc_disp): New function.
(s390_record_calc_disp_vsce): New function.
(s390_record_calc_rl): New function.
(s390_record_gpr_g): New function.
(s390_record_gpr_h): New function.
(s390_record_vr): New function.
(s390_process_record): New function.
(s390_init_linux_record_tdep): New function.
(s390_gdbarch_init): Fill record function slots.
gdb/testsuite/ChangeLog:
* gdb.reverse/s390-mvcle.c: New test.
* gdb.reverse/s390-mvcle.exp: New file.
* lib/gdb.exp: Enable reverse tests on s390*-linux.
On the newly added s390 target, it's possible for a single instruction
to write practically unbounded amount of memory (eg. MVCLE). This caused
a stack overflow when alloca was used.
gdb/ChangeLog:
* record-full.c (record_full_exec_insn): Use xmalloc for temporary
memory storage.
The breakpoint presented in the return statement was not activated while
compiling the test with gcc 4.9.2. Added a dummy statement to allow the
breakpoint again.
2015-10-14 Walfred Tedeschi <walfred.tedeschi@intel.com>
gdb/testsuite:
* i386-mpx-map.c (foo): Add dummy statement to trigger breakpoint.
Change-Id: I5293ca1c7f82a631e1e41cb650c30dd2d09ef3c2
Signed-off-by: Walfred Tedeschi <walfred.tedeschi@intel.com>
Adapts tests to use actual GCC flags, previous used flags were
related to an internal GCC release.
2015-06-18 Walfred Tedeschi <walfred.tedeschi@intel.com>
gdb/testsuite:
* gdb.arch/i386-mpx-map.exp (comp_flags): Use released GCC flags.
* gdb.arch/i386-mpx.exp (comp_flags): Use released GCC flags.
Change-Id: Id4c4551693a8df071ed4b71bb5dfb46a526ed5db
Signed-off-by: Walfred Tedeschi <walfred.tedeschi@intel.com>
Pedro Alves
Antoine Tremblay
Andrew Burgess
Kevin Buettner
Luis Machado
Ruslan Kabatsayev
Pierre-Marie de Rodat
Yao Qi
Andreas Arnez
Joel Brobecker
Josh Stone
Ulrich Weigand
Simon Marchi
Markus Metzger
Tristan Gingold
Tristan Gingold
Doug Evans
Don Breazeal
Jose E. Marchesi
Sandra Loosemore
Dominik Vogt
Marcin Kościelnicki
Jan Kratochvil
Walfred Tedeschi