In the console interpreter, primitive types are resolved in the expression
parser. However that didn't take into consideration the script interface.
gdb/ChangeLog:
* d-namespace.c (d_lookup_symbol): New arg langdef.
All callers updated. Support looking up symbol as a primitive type.
(lookup_module_scope): New arg langdef. All callers updated.
Call d_lookup_symbol directly for simple bare symbols.
gdb/doc/ChangeLog:
* gdb.texinfo (Process Record and Replay): Fix syntax of
"record instruction-history begin, end" and
"record function-call-history begin, end".
2015-09-24 Sandra Loosemore <sandra@codesourcery.com>
gdb/testsuite/
* gdb.cp/classes.exp (test_enums): Generalize regexp to allow
short or char as base type.
FT32 is a Harvard architecture with two address spaces -- RAM and flash.
The patch properly implements the pointer to address conversion method.
There are some other small fixes to handle address spaces.
gdb/
* ft32-tdep.c (ft32_register_type): Return gdbarch_tdep
(gdbarch)->pc_type instead of builtin_func_ptr.
(ft32_pointer_to_address): New function.
(ft32_address_class_type_flags): New function.
(ft32_address_class_type_flags_to_name): New function.
(ft32_address_class_name_to_type_flags): New function.
(ft32_gdbarch_init): Set tdep->pc_type. Call
set_gdbarch_pointer_to_address,
set_gdbarch_address_class_type_flags
set_gdbarch_address_class_name_to_type_flags,
and set_gdbarch_address_class_type_flags_to_name.
* ft32-tdep.h (struct gdbarch_tdep) <pc_type>: New field.
Compilers can materialize renamings of arrays (or of accesses to arrays)
in Ada into variables whose types are references to the actual array
types. Before this change, trying to use such an array renaming yielded
an error in GDB:
(gdb) print my_array(1)
cannot subscript or call a record
(gdb) print my_array_ptr(1)
cannot subscript or call something of type `(null)'
This behavior comes from bad handling for array renamings, in particular
the OP_FUNCALL expression operator handling from ada-lang.c
(ada_evaluate_subexp): in one place we turn the reference into a
pointer, but the code that follows expect the value to be an array.
This patch fixes how we handle references in call/subscript evaluation
so that we turn these references into the actual array values instead of
pointers to them.
gdb/ChangeLog:
* ada-lang.c (ada_evaluate_subexp) <OP_FUNCALL>: When the input
value is a reference, actually dereference it in order to get
the underlying value.
gdb/testsuite/ChangeLog:
* gdb.ada/array_ptr_renaming.exp: New testcase.
* gdb.ada/array_ptr_renaming/foo.adb: New file.
* gdb.ada/array_ptr_renaming/pack.ads: New file.
Tested on x86_64-linux, no regression.
ret->args_u.text is const char *, probe_args is const char *, so no cast
is needed. Found while doing cxx-conversion stuff, since it wouldn't
build in C++.
gdb/ChangeLog:
* stap-probe.c (handle_stap_probe): Remove unnecessary cast.
Two missing consts, found while doing cxx-conversion work. We end up
with a char*, even though we pass a const char* to strstr. I am pushing
this as obvious.
gdb/ChangeLog:
* cli/cli-setshow.c (cmd_show_list): Constify a variable.
* linespec.c (linespec_lexer_lex_string): Same.
When installing a fast tracepoint, we create a jump pad with a
spin-lock. This way, only one thread can collect a given tracepoint at
any time. This test case checks that this lock actually works as
expected.
This test works by creating a function which overrides the in-process
agent library's gdb_collect function. On start up, GDBserver will ask
GDB with the 'qSymbol' packet about symbols present in the inferior.
GDB will reply with the gdb_agent_gdb_collect function from the test
case instead of the one from the agent.
gdb/testsuite/ChangeLog:
* gdb.trace/ftrace-lock.c: New file.
* gdb.trace/ftrace-lock.exp: New file.
This test case makes sure that relocating PC relative instructions does
not change their behaviors. All PC relative AArch64 instructions are
covered. While call and jump (32 bit relative) instructions are covered
on x86.
The test case creates a static array of function pointers for each
supported architecture. Each function in this array tests a specific
instruction using inline assembly. They all need to contain a symbol in
the form of 'set_point\[0-9\]+' and finish by either calling pass or
fail. The number of 'set_pointN' needs to go from 0 to
(ARRAY_SIZE - 1).
The test will:
- look up the number of function pointers in the static array.
- set fast tracepoints on each 'set_point\[0-9\]+' symbol, one in each
functions from 0 to (ARRAY_SIZE - 1).
- run the trace experiment and make sure the pass function is called for
every function.
gdb/testsuite/ChangeLog:
* gdb.arch/insn-reloc.c: New file.
* gdb.arch/ftrace-insn-reloc.exp: New file.
This patch implements compiling agent expressions to native code for
AArch64. This allows us to compile conditions set on fast tracepoints.
The compiled function has the following prologue:
High *------------------------------------------------------*
| LR |
| FP | <- FP
| x1 (ULONGEST *value) |
| x0 (unsigned char *regs) |
Low *------------------------------------------------------*
We save the function's argument on the stack as well as the return
address and the frame pointer. We then set the current frame pointer to
point to the previous one.
The generated code for the expression will freely update the stack
pointer so we use the frame pointer to refer to `*value' and `*regs'.
`*value' needs to be accessed in the epilogue of the function, in order
to set it to whatever is on top of the stack. `*regs' needs to be passed
down to the `gdb_agent_get_raw_reg' function with the `reg' operation.
gdb/gdbserver/ChangeLog:
* linux-aarch64-low-.c: Include ax.h and tracepoint.h.
(enum aarch64_opcodes) <RET>, <SUBS>, <AND>, <ORR>, <ORN>,
<EOR>, <LSLV>, <LSRV>, <ASRV>, <SBFM>, <UBFM>, <CSINC>, <MUL>,
<NOP>: New.
(enum aarch64_condition_codes): New enum.
(w0): New static global.
(fp): Likewise.
(lr): Likewise.
(struct aarch64_memory_operand) <type>: New
MEMORY_OPERAND_POSTINDEX type.
(postindex_memory_operand): New helper function.
(emit_ret): New function.
(emit_load_store_pair): New function, factored out of emit_stp
with support for MEMORY_OPERAND_POSTINDEX.
(emit_stp): Rewrite using emit_load_store_pair.
(emit_ldp): New function.
(emit_load_store): Likewise.
(emit_ldr): Mention post-index instruction in comment.
(emit_ldrh): New function.
(emit_ldrb): New function.
(emit_ldrsw): Mention post-index instruction in comment.
(emit_str): Likewise.
(emit_subs): New function.
(emit_cmp): Likewise.
(emit_and): Likewise.
(emit_orr): Likewise.
(emit_orn): Likewise.
(emit_eor): Likewise.
(emit_mvn): Likewise.
(emit_lslv): Likewise.
(emit_lsrv): Likewise.
(emit_asrv): Likewise.
(emit_mul): Likewise.
(emit_sbfm): Likewise.
(emit_sbfx): Likewise.
(emit_ubfm): Likewise.
(emit_ubfx): Likewise.
(emit_csinc): Likewise.
(emit_cset): Likewise.
(emit_nop): Likewise.
(emit_ops_insns): New helper function.
(emit_pop): Likewise.
(emit_push): Likewise.
(aarch64_emit_prologue): New function.
(aarch64_emit_epilogue): Likewise.
(aarch64_emit_add): Likewise.
(aarch64_emit_sub): Likewise.
(aarch64_emit_mul): Likewise.
(aarch64_emit_lsh): Likewise.
(aarch64_emit_rsh_signed): Likewise.
(aarch64_emit_rsh_unsigned): Likewise.
(aarch64_emit_ext): Likewise.
(aarch64_emit_log_not): Likewise.
(aarch64_emit_bit_and): Likewise.
(aarch64_emit_bit_or): Likewise.
(aarch64_emit_bit_xor): Likewise.
(aarch64_emit_bit_not): Likewise.
(aarch64_emit_equal): Likewise.
(aarch64_emit_less_signed): Likewise.
(aarch64_emit_less_unsigned): Likewise.
(aarch64_emit_ref): Likewise.
(aarch64_emit_if_goto): Likewise.
(aarch64_emit_goto): Likewise.
(aarch64_write_goto_address): Likewise.
(aarch64_emit_const): Likewise.
(aarch64_emit_call): Likewise.
(aarch64_emit_reg): Likewise.
(aarch64_emit_pop): Likewise.
(aarch64_emit_stack_flush): Likewise.
(aarch64_emit_zero_ext): Likewise.
(aarch64_emit_swap): Likewise.
(aarch64_emit_stack_adjust): Likewise.
(aarch64_emit_int_call_1): Likewise.
(aarch64_emit_void_call_2): Likewise.
(aarch64_emit_eq_goto): Likewise.
(aarch64_emit_ne_goto): Likewise.
(aarch64_emit_lt_goto): Likewise.
(aarch64_emit_le_goto): Likewise.
(aarch64_emit_gt_goto): Likewise.
(aarch64_emit_ge_got): Likewise.
(aarch64_emit_ops_impl): New static global variable.
(aarch64_emit_ops): New target function, return
&aarch64_emit_ops_impl.
(struct linux_target_ops): Install it.
This patch adds support for fast tracepoints for aarch64-linux. With this
implementation, a tracepoint can only be placed in a +/- 128MB range of
the jump pad. This is due to the unconditional branch instruction
being limited to a (26 bit << 2) offset from the current PC.
Three target operations are implemented:
- target_install_fast_tracepoint_jump_pad
Building the jump pad the biggest change of this patch. We need to add
functions to emit all instructions needed to save and restore the
current state when the tracepoint is hit. As well as implementing a
lock and creating a collecting_t object identifying the current thread.
Steps performed by the jump pad:
* Save the current state on the stack.
* Push a collecting_t object on the stack. We read the special
tpidr_el0 system register to get the thread ID.
* Spin-lock on the shared memory location of all tracing threads. We
write the address of our collecting_t object there once we have the
lock.
* Call gdb_collect.
* Release the lock.
* Restore the state.
* Execute the replaced instruction which will have been relocated.
* Jump back to the program.
- target_get_thread_area
As implemented in ps_get_thread_area, target_get_thread_area uses ptrace
to fetch the NT_ARM_TLS register. At the architecture level, NT_ARM_TLS
represents the tpidr_el0 system register.
So this ptrace call (if lwpid is the current thread):
~~~
ptrace (PTRACE_GETREGSET, lwpid, NT_ARM_TLS, &iovec);
~~~
Is equivalent to the following instruction:
~~~
msr x0, tpidr_el0
~~~
This instruction is used when creating the collecting_t object that
GDBserver can read to know if a given thread is currently tracing.
So target_get_thread_area must get the same thread IDs as what the jump
pad writes into its collecting_t object.
- target_get_min_fast_tracepoint_insn_len
This just returns 4.
gdb/gdbserver/ChangeLog:
* Makefile.in (linux-aarch64-ipa.o, aarch64-ipa.o): New rules.
* configure.srv (aarch64*-*-linux*): Add linux-aarch64-ipa.o and
aarch64-ipa.o.
* linux-aarch64-ipa.c: New file.
* linux-aarch64-low.c: Include arch/aarch64-insn.h, inttypes.h
and endian.h.
(aarch64_get_thread_area): New target method.
(extract_signed_bitfield): New helper function.
(aarch64_decode_ldr_literal): New function.
(enum aarch64_opcodes): New enum.
(struct aarch64_register): New struct.
(struct aarch64_operand): New struct.
(x0): New static global.
(x1): Likewise.
(x2): Likewise.
(x3): Likewise.
(x4): Likewise.
(w2): Likewise.
(ip0): Likewise.
(sp): Likewise.
(xzr): Likewise.
(aarch64_register): New helper function.
(register_operand): Likewise.
(immediate_operand): Likewise.
(struct aarch64_memory_operand): New struct.
(offset_memory_operand): New helper function.
(preindex_memory_operand): Likewise.
(enum aarch64_system_control_registers): New enum.
(ENCODE): New macro.
(emit_insn): New helper function.
(emit_b): New function.
(emit_bcond): Likewise.
(emit_cb): Likewise.
(emit_tb): Likewise.
(emit_blr): Likewise.
(emit_stp): Likewise.
(emit_ldp_q_offset): Likewise.
(emit_stp_q_offset): Likewise.
(emit_load_store): Likewise.
(emit_ldr): Likewise.
(emit_ldrsw): Likewise.
(emit_str): Likewise.
(emit_ldaxr): Likewise.
(emit_stxr): Likewise.
(emit_stlr): Likewise.
(emit_data_processing_reg): Likewise.
(emit_data_processing): Likewise.
(emit_add): Likewise.
(emit_sub): Likewise.
(emit_mov): Likewise.
(emit_movk): Likewise.
(emit_mov_addr): Likewise.
(emit_mrs): Likewise.
(emit_msr): Likewise.
(emit_sevl): Likewise.
(emit_wfe): Likewise.
(append_insns): Likewise.
(can_encode_int32_in): New helper function.
(aarch64_relocate_instruction): New function.
(aarch64_install_fast_tracepoint_jump_pad): Likewise.
(aarch64_get_min_fast_tracepoint_insn_len): Likewise.
(struct linux_target_ops): Install aarch64_get_thread_area,
aarch64_install_fast_tracepoint_jump_pad and
aarch64_get_min_fast_tracepoint_insn_len.
We will need to decode both ADR and ADRP instructions in GDBserver.
This patch makes common code handle both cases, even if GDB only needs
to decode the ADRP instruction.
gdb/ChangeLog:
* aarch64-tdep.c (aarch64_analyze_prologue): New is_adrp
variable. Call aarch64_decode_adr instead of
aarch64_decode_adrp.
* arch/aarch64-insn.h (aarch64_decode_adrp): Delete.
(aarch64_decode_adr): New function declaration.
* arch/aarch64-insn.c (aarch64_decode_adrp): Delete.
(aarch64_decode_adr): New function, factored out from
aarch64_decode_adrp to decode both adr and adrp instructions.
This patch moves the following functions into the arch/ common
directory, in new files arch/aarch64-insn.{h,c}. They are prefixed with
'aarch64_':
- aarch64_decode_adrp
- aarch64_decode_b
- aarch64_decode_cb
- aarch64_decode_tb
We will need them to implement fast tracepoints in GDBserver.
For consistency, this patch also adds the 'aarch64_' prefix to static
decoding functions that do not need to be shared right now.
V2:
make sure the formatting issues propagated
fix `gdbserver/configure.srv'.
gdb/ChangeLog:
* Makefile.in (ALL_64_TARGET_OBS): Add aarch64-insn.o.
(HFILES_NO_SRCDIR): Add arch/aarch64-insn.h.
(aarch64-insn.o): New rule.
* configure.tgt (aarch64*-*-elf): Add aarch64-insn.o.
(aarch64*-*-linux*): Likewise.
* arch/aarch64-insn.c: New file.
* arch/aarch64-insn.h: New file.
* aarch64-tdep.c: Include arch/aarch64-insn.h.
(aarch64_debug): Move to arch/aarch64-insn.c. Declare in
arch/aarch64-insn.h.
(decode_add_sub_imm): Rename to ...
(aarch64_decode_add_sub_imm): ... this.
(decode_adrp): Rename to ...
(aarch64_decode_adrp): ... this. Move to arch/aarch64-insn.c.
Declare in arch/aarch64-insn.h.
(decode_b): Rename to ...
(aarch64_decode_b): ... this. Move to arch/aarch64-insn.c.
Declare in arch/aarch64-insn.h.
(decode_bcond): Rename to ...
(aarch64_decode_bcond): ... this. Move to arch/aarch64-insn.c.
Declare in arch/aarch64-insn.h.
(decode_br): Rename to ...
(aarch64_decode_br): ... this.
(decode_cb): Rename to ...
(aarch64_decode_cb): ... this. Move to arch/aarch64-insn.c.
Declare in arch/aarch64-insn.h.
(decode_eret): Rename to ...
(aarch64_decode_eret): ... this.
(decode_movz): Rename to ...
(aarch64_decode_movz): ... this.
(decode_orr_shifted_register_x): Rename to ...
(aarch64_decode_orr_shifted_register_x): ... this.
(decode_ret): Rename to ...
(aarch64_decode_ret): ... this.
(decode_stp_offset): Rename to ...
(aarch64_decode_stp_offset): ... this.
(decode_stp_offset_wb): Rename to ...
(aarch64_decode_stp_offset_wb): ... this.
(decode_stur): Rename to ...
(aarch64_decode_stur): ... this.
(decode_tb): Rename to ...
(aarch64_decode_tb): ... this. Move to arch/aarch64-insn.c.
Declare in arch/aarch64-insn.h.
(aarch64_analyze_prologue): Adjust calls to renamed functions.
gdb/gdbserver/ChangeLog:
* Makefile.in (aarch64-insn.o): New rule.
* configure.srv (aarch64*-*-linux*): Add aarch64-insn.o.
Hi,
I see the following build warning with recent GCC built from mainline,
aarch64-none-linux-gnu-gcc -g -O2 -I. -I/home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver -I/home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/../common -I/home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/../regformats -I/home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/.. -I/home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/../../include -I/home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/../gnulib/import -Ibuild-gnulib-gdbserver/import -Wall -Wpointer-arith -Wformat-nonliteral -Wno-char-subscripts -Wempty-body -Wdeclaration-after-statement -Werror -DGDBSERVER -DCONFIG_UST_GDB_INTEGRATION -fPIC -DIN_PROCESS_AGENT -fvisibility=hidden -c -o ax-ipa.o -MT ax-ipa.o -MMD -MP -MF .deps/ax-ipa.Tpo `echo " -Wall -Wpointer-arith -Wformat-nonliteral -Wno-char-subscripts -Wempty-body -Wdeclaration-after-statement " | sed "s/ -Wformat-nonliteral / -Wno-format-nonliteral /g"` /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/ax.c
/home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/ax.c:73:28: error: 'gdb_agent_op_sizes' defined but not used [-Werror=unused-const-variable]
static const unsigned char gdb_agent_op_sizes [gdb_agent_op_last] =
^
cc1: all warnings being treated as errors
gdb_agent_op_sizes is only used in function is_goto_target, which is
defined inside #ifndef IN_PROCESS_AGENT. This warning is not arch
specific, so GCC mainline for other targets should produce this warning
too, although this warning is triggered by enabling aarch64 fast
tracepoint. The fix is to move gdb_agent_op_sizes to
gdb/gdbserver:
2015-09-21 Yao Qi <yao.qi@linaro.org>
* ax.c [!IN_PROCESS_AGENT] (gdb_agent_op_sizes): Define it.
This patch is to remove max_jump_pad_size which isn't used else where,
and it causes a recent gcc warning like this,
gdb/gdbserver/tracepoint.c:2920:18: error: 'max_jump_pad_size' defined but not used [-Werror=unused-const-variable]
static const int max_jump_pad_size = 0x100;
^
cc1: all warnings being treated as errors
This variable max_jump_pad_size wasn't used since it was added in 2010
by https://sourceware.org/ml/gdb-patches/2010-06/msg00002.html
gdb/gdbserver:
2015-09-21 Yao Qi <yao.qi@linaro.org>
* tracepoint.c (max_jump_pad_size): Remove.
We have noticed that GDB would sometimes crash trying to print
from a nested function the value of a variable declared in an
enclosing scope. This appears to be target dependent, although
that correlation might only be fortuitious. We noticed the issue
on x86_64-darwin, x86-vxworks6 and x86-solaris. The investigation
was done on Darwin.
This is a new feature that was introduced by:
commit 63e43d3aed
Date: Thu Feb 5 17:00:06 2015 +0100
DWARF: handle non-local references in nested functions
We can reproduce the problem with one of the testcases that was
added with the patch (gdb.base/nested-subp1.exp), where we have...
18 int
19 foo (int i1)
20 {
21 int
22 nested (int i2)
23 {
[...]
27 return i1 * i2; /* STOP */
28 }
... After building the example program, and running until line 27,
try printing the value of "i1":
% gdb gdb.base/nested-subp1
(gdb) break foo.c:27
(gdb) run
Breakpoint 1, nested (i2=2) at /[...]/nested-subp1.c:27
27 return i1 * i2; /* STOP */
(gdb) p i1
[1] 73090 segmentation fault ../gdb -q gdb.base/nested-subp1
Ooops!
What happens is that, because the reference is non-local, we are trying
to follow the function's static link, which does...
/* If we don't know how to compute FRAME's base address, don't give up:
maybe the frame we are looking for is upper in the stace frame. */
if (framefunc != NULL
&& SYMBOL_BLOCK_OPS (framefunc)->get_frame_base != NULL
&& (SYMBOL_BLOCK_OPS (framefunc)->get_frame_base (framefunc, frame)
== upper_frame_base))
... or, in other words, calls the get_frame_base "method" of
framefunc's struct symbol_block_ops data. This resolves to
the block_op_get_frame_base function.
Looking at the function's implementation, we see:
struct dwarf2_locexpr_baton *dlbaton;
[...]
dlbaton = SYMBOL_LOCATION_BATON (framefunc);
[...]
result = dwarf2_evaluate_loc_desc (type, frame, start, length,
dlbaton->per_cu);
^^^^^^^^^^^^^^^
Printing dlbaton->per_cu gives a value that seems fairly bogus for
a memory address (0x60). Because of it, dwarf2_evaluate_loc_desc
then crashes trying to dereference it.
What's different on Darwin compared to Linux is that the function's
frame base is encoded using the following form:
.byte 0x40 # uleb128 0x40; (DW_AT_frame_base)
.byte 0x6 # uleb128 0x6; (DW_FORM_data4)
... and so dwarf2_symbol_mark_computed ends up creating
a SYMBOL_LOCATION_BATON as a struct dwarf2_loclist_baton:
if (attr_form_is_section_offset (attr)
/* .debug_loc{,.dwo} may not exist at all, or the offset may be outside
the section. If so, fall through to the complaint in the
other branch. */
&& DW_UNSND (attr) < dwarf2_section_size (objfile, section))
{
struct dwarf2_loclist_baton *baton;
[...]
SYMBOL_LOCATION_BATON (sym) = baton;
However, if you look more closely at block_op_get_frame_base's
implementation, you'll notice that the function extracts the
symbol's SYMBOL_LOCATION_BATON as a dwarf2_locexpr_baton
(a DWARF _expression_ rather than a _location list_).
That's why we end up decoding the DLBATON improperly, and thus
pass a random dlbaton->per_cu when calling dwarf2_evaluate_loc_desc.
This works on x86_64-linux, because we indeed have the frame base
described using a different form:
.uleb128 0x40 # (DW_AT_frame_base)
.uleb128 0x18 # (DW_FORM_exprloc)
This patch fixes the issue by doing what we do for most (if not all)
other such methods: providing one implementation each for loc-list,
and loc-expr. Both implementations are nearly identical, so perhaps
we might later want to improve this. But this patch first tries to
fix the crash first, leaving the design issue for later.
gdb/ChangeLog:
* dwarf2loc.c (locexpr_get_frame_base): Renames
block_op_get_frame_base.
(dwarf2_block_frame_base_locexpr_funcs): Replace reference to
block_op_get_frame_base by reference to locexpr_get_frame_base.
(loclist_get_frame_base): New function, near identical copy of
locexpr_get_frame_base.
(dwarf2_block_frame_base_loclist_funcs): Replace reference to
block_op_get_frame_base by reference to loclist_get_frame_base.
Tested on x86_64-darwin (AdaCore testsuite), and x86_64-linux
(official testsuite).
bfd/ChangeLog:
* targets.c (enum bfd_flavour): Add comment.
(bfd_flavour_name): New function.
* bfd-in2.h: Regenerate.
gdb/ChangeLog:
* findvar.c (default_read_var_value) <LOC_UNRESOLVED>: Include the
kind of minimal symbol in the error message.
* objfiles.c (objfile_flavour_name): New function.
* objfiles.h (objfile_flavour_name): Declare.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-bad-unresolved.c: New file.
* gdb.dwarf2/dw2-bad-unresolved.exp: New file.
2015-09-18 Sandra Loosemore <sandra@codesourcery.com>
gdb/testsuite/
* gdb.mi/mi-pending.exp: Don't use directory prefix when setting
the pending breakpoint. Remove timeout override for "Run till
MI pending breakpoint on pendfunc3 on thread 2" test.
With the kernle fix <http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/356511.html>,
aarch64 GDB is able to read the base of thread area of 32-bit arm
program through NT_ARM_TLS.
This patch is to teach both GDB and GDBserver to read the base of
thread area correctly in the multi-arch case. A new function
aarch64_ps_get_thread_area is added, and is shared between GDB and
GDBserver.
With this patch applied, the following fails in multi-arch testing
(GDB is aarch64 but the test cases are arm) are fixed,
-FAIL: gdb.threads/tls-nodebug.exp: thread local storage
-FAIL: gdb.threads/tls-shared.exp: print thread local storage variable
-FAIL: gdb.threads/tls-so_extern.exp: print thread local storage variable
-FAIL: gdb.threads/tls-var.exp: print tls_var
-FAIL: gdb.threads/tls.exp: first thread local storage
-FAIL: gdb.threads/tls.exp: first another thread local storage
-FAIL: gdb.threads/tls.exp: p a_thread_local
-FAIL: gdb.threads/tls.exp: p file2_thread_local
-FAIL: gdb.threads/tls.exp: p a_thread_local second time
gdb:
2015-09-18 Yao Qi <yao.qi@linaro.org>
* nat/aarch64-linux.c: Include elf/common.h,
nat/gdb_ptrace.h, asm/ptrace.h and sys/uio.h.
(aarch64_ps_get_thread_area): New function.
* nat/aarch64-linux.h: Include gdb_proc_service.h.
(aarch64_ps_get_thread_area): Declare.
* aarch64-linux-nat.c (ps_get_thread_area): Call
aarch64_ps_get_thread_area.
gdb/gdbserver:
2015-09-18 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c: Don't include sys/uio.h.
(ps_get_thread_area): Call aarch64_ps_get_thread_area.
In all-stop mode, record btrace maintains the old behaviour of an implicit
scheduler-locking on.
Now that we added a scheduler-locking mode to model this old behaviour, we
don't need the respective code in record btrace anymore. Remove it.
For all-stop targets, step inferior_ptid and continue other threads matching
the argument ptid. Assert that inferior_ptid matches the argument ptid.
This should make record btrace honour scheduler-locking.
gdb/
* record-btrace.c (record_btrace_resume): Honour scheduler-locking.
testsuite/
* gdb.btrace/multi-thread-step.exp: Test scheduler-locking on, step,
and replay.
Record targets behave as if scheduler-locking were on in replay mode. Add a
new scheduler-locking option "replay" to make this implicit behaviour explicit.
It behaves like "on" in replay mode and like "off" in record mode.
By making the current behaviour a scheduler-locking option, we allow the user
to change it. Since it is the current behaviour, this new option is also
the new default.
One caveat is that when resuming a thread that is at the end of its execution
history, record btrace implicitly stops replaying other threads and resumes
the entire process. This is a convenience feature to not require the user
to explicitly move all other threads to the end of their execution histories
before being able to resume the process.
We mimick this behaviour with scheduler-locking replay and move it from
record-btrace into infrun. With all-stop on top of non-stop, we can't do
this in record-btrace anymore.
Record full does not really support multi-threading and is therefore not
impacted. If it were extended to support multi-threading, it would 'benefit'
from this change. The good thing is that all record targets will behave the
same with respect to scheduler-locking.
I put the code for this into clear_proceed_status. It also sends the
about_to_proceed notification.
gdb/
* NEWS: Announce new scheduler-locking mode.
* infrun.c (schedlock_replay): New.
(scheduler_enums): Add schedlock_replay.
(scheduler_mode): Change default to schedlock_replay.
(user_visible_resume_ptid): Handle schedlock_replay.
(clear_proceed_status_thread): Stop replaying if resumed thread is
not replaying.
(schedlock_applies): Handle schedlock_replay.
(_initialize_infrun): Document new scheduler-locking mode.
* record-btrace.c (record_btrace_resume): Remove code to stop other
threads when not replaying the resumed thread.
doc/
* gdb.texinfo (All-Stop Mode): Describe new scheduler-locking mode.
Add a new target method to_record_will_replay to query if there is a record
target that will replay at least one thread matching the argument PTID if it
were executed in the argument execution direction.
gdb/
* record-btrace.c ((record_btrace_will_replay): New.
(init_record_btrace_ops): Initialize to_record_will_replay.
* record-full.c ((record_full_will_replay): New.
(init_record_full_ops): Initialize to_record_will_replay.
* target-delegates.c: Regenerated.
* target.c (target_record_will_replay): New.
* target.h (struct target_ops) <to_record_will_replay>: New.
(target_record_will_replay): New.
Signed-off-by: Markus Metzger <markus.t.metzger@intel.com>
The record btrace target does not allow accessing memory and storing registers
while replaying. For multi-threaded applications, this prevents those
accesses also for threads that are at the end of their execution history as
long as at least one thread is replaying.
Change this to only check if the selected thread is replaying. This allows
threads that are at the end of their execution history to read and write
memory and to store registers.
Also change the error message to reflect this change.
gdb/
* record-btrace.c (record_btrace_xfer_partial)
(record_btrace_store_registers, record_btrace_prepare_to_store):
Call record_btrace_is_replaying with inferior_ptid instead of
minus_one_ptid.
(record_btrace_store_registers): Change error message.
The to_record_is_replaying target method is used to query record targets if
they are replaying. This is currently interpreted as "is any thread being
replayed".
Add a PTID argument and change the interpretation to "is any thread matching
PTID being replayed".
Change all users to pass minus_one_ptid to preserve the old meaning.
The record full target does not really support multi-threading and ignores
the PTID argument.
gdb/
* record-btrace.c (record_btrace_is_replaying): Add ptid argument.
Update users to pass minus_one_ptid.
* record-full.c (record_full_is_replaying): Add ptid argument (ignored).
* record.c (cmd_record_delete): Pass inferior_ptid to
target_record_is_replaying.
* target-delegates.c: Regenerated.
* target.c (target_record_is_replaying): Add ptid argument.
* target.h (struct target_ops) <to_record_is_replaying>: Add ptid
argument.
(target_record_is_replaying): Add ptid argument.
A thread that runs out of its execution history is stopped. We already set
stop_pc and call stop_waiting. But we do not switch to the stopped thread.
In normal_stop, we call finish_thread_state_cleanup to set a thread's running
state. In all-stop mode, we call it with minus_one_ptid; in non-stop mode, we
only call it for inferior_ptid.
If in non-stop mode normal_stop is called on behalf of a thread that is not
inferior_ptid, that other thread will still be reported as running. If it is
actually stopped it can't be resumed again.
Record targets traditionally don't support non-stop and only resume
inferior_ptid. So this has not been a problem, so far.
Switch to the eventing thread for NO_HISTORY events as preparation to support
non-stop for the record btrace target.
gdb/
* infrun.c (handle_inferior_event_1): Switch to the eventing thread
in the TARKET_WAITKIND_NO_HISTORY case.
The record btrace target runs synchronous with GDB. That is, GDB steps
resumed threads in record btrace's to_wait method. Without GDB calling
to_wait, nothing happens 'on the target'.
Check for further expected events in to_wait before reporting the current
event and mark record btrace's async event handler in async mode.
gdb/
* record-btrace.c (record_btrace_maybe_mark_async_event): New.
(record_btrace_wait): Call record_btrace_maybe_mark_async_event.
Get_current_frame uses inferior_ptid. In record_btrace_start_replaying,
we need to get the current frame of the argument thread. So far, this
has always been inferior_ptid. With non-stop, this is not guaranteed.
Temporarily set inferior_ptid to the ptid of the argument thread.
We already temporarily set the argument thread's executing flag to false.
Move both into a new function get_thread_current_frame that does the temporary
adjustments, calls get_current_frame, and restores the previous values.
gdb/
* record-btrace.c (get_thread_current_frame): New.
(record_btrace_start_replaying): Call get_thread_current_frame.
The record targets are implicitly schedlocked. They only step the current
thread and keep other threads where they are.
Change record btrace to step all requested threads in to_resume.
For maintenance and debugging, we keep the old behaviour when the target below
is not non-stop. Enable with "maint set target-non-stop on".
gdb/
* record-btrace.c (record_btrace_resume_thread): A move request
overwrites a previous move request.
(record_btrace_find_resume_thread): Removed.
(record_btrace_resume): Resume all requested threads.
Record btrace's to_wait method picks a single thread to step. When passed
minus_one_ptid, it picks the current thread. All other threads remain where
they are.
Change this to step all resumed threads together, one step at a time, until
the first thread reports an event.
We do delay reporting NO_HISTORY events until there are no other events to
report to prevent threads at the end of their execution history from starving
other threads.
We keep threads at the end of their execution history moving and replaying
until we announce their stop in to_wait. This shouldn't really be user-visible
but its a detail worth mentioning.
Since record btrace's to_resume method also picks only a single thread to
resume, there shouldn't be a difference with the current all-stop.
With non-stop or all-stop on top of non-stop, we will see differences. The
behaviour should be more natural as we're moving all threads.
gdb/
* record-btrace.c: Include vec.h.
(record_btrace_find_thread_to_move): Removed.
(btrace_step_no_resumed, btrace_step_again)
(record_btrace_stop_replaying_at_end): New.
(record_btrace_cancel_resume): Call record_btrace_stop_replaying_at_end.
(record_btrace_single_step_forward): Remove calls to
record_btrace_stop_replaying.
(record_btrace_step_thread): Do only one step for BTHR_CONT and
BTHR_RCONT. Keep threads at the end of their history moving.
(record_btrace_wait): Call record_btrace_step_thread for all threads
until one reports an event. Call record_btrace_stop_replaying_at_end
for the eventing thread.
If a single-step ended right at the end of the execution history, we forgot
to announce that. Fix it.
gdb/
* record-btrace.c (record_btrace_single_step_forward): Return
NO_HISTORY if a step brings us to the end of the execution history.
Breakpoints are only checked for BTHR_CONT and BTHR_RCONT stepping requests.
A BTHR_STEP and BTHR_RSTEP request will always report stopped without reason.
Since breakpoints are reported correctly, I assume infrun is handling this.
Move the breakpoint check into the btrace single stepping functions. This
will cause us to report breakpoint hits now also for single-step requests.
One thing to notice is that
- when executing forwards, the breakpoint is checked before 'executing'
the instruction, i.e. before moving the PC to the next instruction.
- when executing backwards, the breakpoint is checked after 'executing'
the instruction, i.e. after moving the PC to the preceding instruction
in the recorded execution.
There is code in infrun (see, for example proceed and adjust_pc_after_break)
that handles this and also depends on this behaviour.
gdb/
* record-btrace.c (record_btrace_step_thread): Move breakpoint check
to ...
(record_btrace_single_step_forward): ... here and
(record_btrace_single_step_backward): ... here.
The code for BTHR_STEP and BTHR_CONT is fairly similar. Extract the common
parts into a new function record_btrace_single_step_forward. The function
returns TARGET_WAITKIND_SPURIOUS to indicate that the single-step completed
without triggering a trap.
Same for BTHR_RSTEP and BTHR_RCONT.
gdb/
* record-btrace.c (btrace_step_spurious)
(record_btrace_single_step_forward)
(record_btrace_single_step_backward): New.
(record_btrace_step_thread): Call record_btrace_single_step_forward
and record_btrace_single_step_backward.
There are two places where record_btrace_step_thread checks for a breakpoint
at the current replay position. Move this code into its own function.
gdb/
* record-btrace.c (record_btrace_replay_at_breakpoint): New.
(record_btrace_step_thread): Call record_btrace_replay_at_breakpoint.
Add support for the to_stop target method to the btrace record target.
gdb/
* btrace.h (enum btrace_thread_flag) <BTHR_STOP>: New.
* record-btrace (record_btrace_resume_thread): Clear BTHR_STOP.
(record_btrace_find_thread_to_move): Also accept threads that have
BTHR_STOP set.
(btrace_step_stopped_on_request, record_btrace_stop): New.
(record_btrace_step_thread): Support BTHR_STOP.
(record_btrace_wait): Also clear BTHR_STOP when stopping other threads.
(init_record_btrace_ops): Initialize to_stop.
The record btrace target stops other threads in non-stop mode after stepping
the to-be-resumed thread.
The check is done on the non_stop variable. It should rather be done on
target_is_non_stop_p (). With all-stop on top of non-stop, infrun will
take care of stopping other threads.
gdb/
* record-btrace.c (record_btrace_wait): Replace non_stop check with
target_is_non_stop_p ().
This patch adds a test case for tracepoints with a condition expression.
Each case will test a condition against the number of frames that should
have been traced. Some of these tests fail on x86_64 and others on
i386, which have been marked as known failures for now, see PR/18955.
gdb/testsuite/ChangeLog:
2015-09-17 Pierre Langlois <pierre.langlois@arm.com>
Yao Qi <yao.qi@linaro.org>
* gdb.trace/trace-condition.c: New file.
* gdb.trace/trace-condition.exp: New file.
This patch fixes the argument passed to compiled_cond. It should be
regs buffer instead of tracepoint_hit_ctx. Test case is added as
well for testing compiled-cond.
gdb/gdbserver/ChangeLog
2015-09-16 Wei-cheng Wang <cole945@gmail.com>
* tracepoint.c (eval_result_type): Change prototype.
(condition_true_at_tracepoint): Fix argument to compiled_cond.
gdb/testsuite/ChangeLog
2015-09-16 Wei-cheng Wang <cole945@gmail.com>
* gdb.trace/ftrace.exp: (test_ftrace_condition) New function
for testing bytecode compilation.
On software single-step targets that don't support displaced stepping,
threads keep hitting each other's single-step breakpoints, and then
GDB needs to pause all threads to step past those. The end result is
that progress in the main thread will be slower and it may take a bit
longer for the signal to be queued. This patch bumps the timeout on
such targets.
gdb/testsuite/ChangeLog:
2015-09-16 Pedro Alves <palves@redhat.com>
Sandra Loosemore <sandra@codesourcery.com>
* gdb.threads/non-stop-fair-events.c (timeout): New global.
(SECONDS): Redefine.
(main): Call pthread_kill and alarm early.
* gdb.threads/non-stop-fair-events.exp: Probe displaced stepping
support.
(test): If the target can't hardware step and doesn't support
displaced stepping, increase the timeout.
If we enable infrun debug running this test, it quickly fails with a
full expect buffer. That can be simply handled with a couple
exp_continues. As it's annoying to hack this every time we need to
debug the test, this patch adds bits to enable debugging support
easily, with a one-line change.
And then, if any iteration of the test fails, we end up with a long
cascade of time outs. Just bail out when we see the first fail.
gdb/testsuite/
2015-09-16 Pedro Alves <palves@redhat.com>
* gdb.threads/non-stop-fair-events.exp (gdb_test_no_anchor)
(enable_debug): New procedures.
(test): Use them. Bail out if waiting for threads fails.
(top level): Bail out if a test fails.
This patch adds gdb.asm/aarch64.inc, so asm-source.exp isn't skipped
on aarch64 any more.
gdb/testsuite:
2015-09-16 Yao Qi <yao.qi@linaro.org>
* gdb.asm/asm-source.exp: Set asm-arch for
aarch64*-*-* target.
* gdb.asm/aarch64.inc: New file.
This change is relevant only for standard DWARF (as opposed to the GNAT
encodings extensions): at the time of writing it only makes a difference
with GCC patches that are to be integrated: see the patch series
submission at
<https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01353.html>.
Given the following Ada declarations:
subtype Small_Int is Natural range 0 .. 100;
type R_Type (L : Small_Int := 0) is record
S : String (1 .. L);
end record;
type A_Type is array (Natural range <>) of R_Type;
A : A_Type := (1 => (L => 0, S => ""),
2 => (L => 2, S => "ab"));
Before this change, we would get the following GDB session:
(gdb) ptype a
type = array (1 .. 2) of foo.r_type <packed: 838-bit elements>
This is wrong: "a" is not a packed array. This output comes from the
fact that, because R_Type has a dynamic size (with a maximum), the
compiler has to describe in the debugging information the size allocated
for each array element (i.e. the stride, in DWARF parlance: see
DW_AT_byte_stride). Ada type printing currently assumes that arrays
with a stride are packed, hence the above output.
In practice, GNAT never performs bit-packing for arrays that contain
variable-sized elements. Leveraging this fact, this patch enhances type
printing so that ptype does not pretend that arrays are packed when they
have a stride and they contain dynamic elements. After this change, we
get the following expected output:
(gdb) ptype a
type = array (1 .. 2) of foo.r_type
gdb/ChangeLog:
* ada-typeprint.c (print_array_type): Do not describe arrays as
packed when they embed dynamic elements.
gdb/testsuite/ChangeLog:
* gdb.ada/array_of_variable_length.exp: New testcase.
* gdb.ada/array_of_variable_length/foo.adb: New file.
* gdb.ada/array_of_variable_length/pck.adb: New file.
* gdb.ada/array_of_variable_length/pck.ads: New file.
Tested on x86_64-linux, no regression.
clang names the local variable t_structs_a.buf.
gdb/testsuite/ChangeLog:
* gdb.base/callfuncs.exp (do_function_calls): Handle clang naming
of function static local variable.
The previous manual change was wrong. The vfork parent thread ID
should be reported with the usual "thread" magic register:
Sending packet: $vCont;c:p7260.7260#1e...Packet received: OK
- Notification received: Stop:T05vforkdone:;
+ Notification received: Stop:T05vforkdone:;thread:p7260.7260
^^^^^^^^^^^^^^^^^
This is already how the parent is reported in the vfork/fork events,
and is actually what the fix made gdbserver do. Following the
documentation change, the event would have been reported like this
instead:
Notification received: Stop:T05vforkdone:p7260.7260
gdb/doc/ChangeLog:
2015-09-15 Pedro Alves <palves@redhat.com>
PR remote/18965
* gdb.texinfo (Stop Reply Packets): Revert previous change to
the vforkdone description.
ppc64le loses control when stepping between two PLT-called functions inside
a shared library:
29 shlib_second (); /* first-hit */^M
(gdb) PASS: gdb.base/solib-intra-step.exp: first-hit
step^M
^M
Program received signal SIGABRT, Aborted.^M
0x00003fffb7cbe578 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56^M
56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);^M
(gdb) FAIL: gdb.base/solib-intra-step.exp: second-hit
->
29 shlib_second (); /* first-hit */^M
(gdb) PASS: gdb.base/solib-intra-step.exp: first-hit
step^M
shlib_second () at ./gdb.base/solib-intra-step-lib.c:23^M
23 abort (); /* second-hit */^M
(gdb) PASS: gdb.base/solib-intra-step.exp: second-hit
This is because gdbarch_skip_trampoline_code() will resolve the final function
as shlib_second+0 and place there the breakpoint, but ld.so will jump after
the breakpoint - at shlib_second+8 - as it is ELFv2 local symbol optimization:
Dump of assembler code for function shlib_second:
0x0000000000000804 <+0>: addis r2,r12,2
0x0000000000000808 <+4>: addi r2,r2,30668
0x000000000000080c <+8>: mflr r0
Currently gdbarch_skip_entrypoint() has been called in skip_prologue_sal() and
fill_in_stop_func() but that is not enough. I believe
gdbarch_skip_entrypoint() should be called after every
gdbarch_skip_trampoline_code().
gdb/ChangeLog
2015-09-15 Jan Kratochvil <jan.kratochvil@redhat.com>
* linespec.c (minsym_found): Call gdbarch_skip_entrypoint.
* ppc64-tdep.c (ppc64_skip_trampoline_code): Rename to ...
(ppc64_skip_trampoline_code_1): ... here.
(ppc64_skip_trampoline_code): New wrapper function.
* symtab.c (find_function_start_sal): Call gdbarch_skip_entrypoint.
gdb/testsuite/ChangeLog
2015-09-15 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.opt/solib-intra-step-lib.c: New file.
* gdb.opt/solib-intra-step-main.c: New file.
* gdb.opt/solib-intra-step.exp: New file.
gdb/ChangeLog -> gdb/gdbserver/ChangeLog
2015-09-15 Pedro Alves <palves@redhat.com>
PR remote/18965
* remote-utils.c (prepare_resume_reply): Merge
TARGET_WAITKIND_VFORK_DONE switch case with the
TARGET_WAITKIND_FORKED case.
The vforkdone stop reply misses indicating the thread ID of the vfork
parent which the event relates to:
@cindex vfork events, remote reply
@item vfork
The packet indicates that @code{vfork} was called, and @var{r}
is the thread ID of the new child process. Refer to
@ref{thread-id syntax} for the format of the @var{thread-id}
field. This packet is only applicable to targets that support
vfork events.
@cindex vforkdone events, remote reply
@item vforkdone
The packet indicates that a child process created by a vfork
has either called @code{exec} or terminated, so that the
address spaces of the parent and child process are no longer
shared. The @var{r} part is ignored. This packet is only
applicable to targets that support vforkdone events.
Unfortunately, this is not just a documentation issue. GDBserver
is really not specifying the thread ID. I noticed because
in non-stop mode, gdb complains:
[Thread 6089.6089] #1 stopped.
#0 0x0000003615a011f0 in ?? ()
0x0000003615a011f0 in ?? ()
(gdb) set debug remote 1
(gdb) c
Continuing.
Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;#5f...Packet received: OK
Sending packet: $vCont;c:p17c9.17c9#88...Packet received: OK
Notification received: Stop:T05vfork:p17ce.17ce;06:40d7ffffff7f0000;07:30d7ffffff7f0000;10:e4c9eb1536000000;thread:p17c9.17c9;core:2;
Sending packet: $vStopped#55...Packet received: OK
Sending packet: $D;17ce#af...Packet received: OK
Sending packet: $vCont;c:p17c9.17c9#88...Packet received: OK
Notification received: Stop:T05vforkdone:;
No process or thread specified in stop reply: T05vforkdone:;
(gdb)
This is not non-stop-mode-specific, however. Consider e.g., that in
all-stop, you may be debugging more than one process at the same time.
You continue, and both processes vfork. So when you next get a
T05vforkdone, there's no way to tell which of the parent processes is
done with the vfork.
Tests will be added later.
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-09-15 Pedro Alves <palves@redhat.com>
PR remote/18965
* remote-utils.c (prepare_resume_reply): Merge
TARGET_WAITKIND_VFORK_DONE switch case with the
TARGET_WAITKIND_FORKED case.
gdb/doc/ChangeLog:
2015-09-15 Pedro Alves <palves@redhat.com>
PR remote/18965
* gdb.texinfo (Stop Reply Packets): Explain that vforkdone's 'r'
part indicates the thread ID of the parent process.
gdb.threads/non-ldr-exc-3.exp is sometimes failing like this:
[Switching to Thread 6831.6832]
Breakpoint 2, thread_execler (arg=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.threads/non-ldr-exc-3.c:41
41 if (execl (image, image, argv1, NULL) == -1) /* break-here */
PASS: gdb.threads/non-ldr-exc-3.exp: lock-sched=on,non-stop=off: continue to breakpoint
(gdb) set scheduler-locking on
(gdb) FAIL: gdb.threads/non-ldr-exc-3.exp: lock-sched=on,non-stop=off: set scheduler-locking on
The problem is that the gdb_test_multiple is missing the prompt
anchor. The problem was introduced by 2fd33e9448. This reverts the
hunk that introduced the problem, reverting back to
gdb_continue_to_breakpoint.
gdb/testsuite/ChangeLog:
2015-09-15 Pedro Alves <palves@redhat.com>
* gdb.threads/non-ldr-exc-3.exp (do_test): Use
gdb_continue_to_breakpoint instead of gdb_test_multiple.
Nowadays, GDB only knows whether architecture supports hardware single
step or software single step (through gdbarch hook software_single_step),
and for a given instruction or instruction sequence, GDB knows how to
do single step (hardware or software). However, GDB doesn't know whether
the target supports hardware single step. It is possible that the
architecture doesn't support hardware single step, such as arm, but
the target supports, such as simulator. This was discussed in this
thread https://www.sourceware.org/ml/gdb/2009-12/msg00033.html before.
I encounter this problem for aarch64 multi-arch support. When aarch64
debugs arm program, gdbarch is arm, so software single step is still
used. However, the underneath linux kernel does support hardware
single step, so IWBN to use it.
This patch is to add a new target_ops hook to_can_do_single_step, and
only use it in arm_linux_software_single_step to decide whether or not
to use hardware single step. On the native aarch64 linux target, 1 is
returned. On other targets, -1 is returned. On the remote target, if
the target supports s and S actions in the vCont? reply, then target
can do single step. However, old GDBserver will send s and S in the
reply to vCont?, which will confuse new GDB. For example, old GDBserver
on arm-linux will send s and S in the reply to vCont?, but it doesn't
support hardware single step. On the other hand, new GDBserver, on
arm-linux for example, will not send s and S in the reply to vCont?,
but old GDB thinks it doesn't support vCont packet at all. In order
to address this problem, I add a new qSupported feature vContSupported,
which indicates GDB wants to know the supported actions in the reply
to vCont?, and qSupported response contains vContSupported if the
stub is able tell supported vCont actions in the reply of vCont?.
If the patched GDB talks with patched GDBserver on x86, the RSP traffic
is like this:
-> $qSupported:...+;vContSupported+
<- ...+;vContSupported+
...
-> $vCont?
<- vCont;c;C;t;s;S;r
then, GDB knows the stub can do single step, and may stop using software
single step even the architecture doesn't support hardware single step.
If the patched GDB talks with patched GDBserver on arm, the last vCont?
reply will become:
<- vCont;c;C;t
GDB thinks the target doesn't support single step, so it will use software
single step.
If the patched GDB talks with unpatched GDBserver, the RSP traffic is like
this:
-> $qSupported:...+;vContSupported+
<- ...+
...
-> $vCont?
<- vCont;c;C;t;s;S;r
although GDBserver returns s and S, GDB still thinks GDBserver may not
support single step because it doesn't support vContSupported.
If the unpatched GDB talks with patched GDBserver on x86, the RSP traffic
is like:
-> $qSupported:...+;
<- ...+;vContSupported+
...
-> $vCont?
<- vCont;c;C;t;s;S;r
Since GDB doesn't sent vContSupported in the qSupported feature, GDBserver
sends s and S regardless of the support of hardware single step.
gdb:
2015-09-15 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (aarch64_linux_can_do_single_step): New
function.
(_initialize_aarch64_linux_nat): Install it to to_can_do_single_step.
* arm-linux-tdep.c (arm_linux_software_single_step): Return 0
if target_can_do_single_step returns 1.
* remote.c (struct vCont_action_support) <s, S>: New fields.
(PACKET_vContSupported): New enum.
(remote_protocol_features): New element for vContSupported.
(remote_query_supported): Append "vContSupported+".
(remote_vcont_probe): Remove support_s and support_S, use
rs->supports_vCont.s and rs->supports_vCont.S instead. Disable
vCont packet if c and C actions are not supported.
(remote_can_do_single_step): New function.
(init_remote_ops): Install it to to_can_do_single_step.
(_initialize_remote): Call add_packet_config_cmd.
* target.h (struct target_ops) <to_can_do_single_step>: New field.
(target_can_do_single_step): New macro.
* target-delegates.c: Re-generated.
gdb/gdbserver:
2015-09-15 Yao Qi <yao.qi@linaro.org>
* server.c (vCont_supported): New global variable.
(handle_query): Set vCont_supported to 1 if "vContSupported+"
matches. Append ";vContSupported+" to own_buf.
(handle_v_requests): Append ";s;S" to own_buf if target supports
hardware single step or vCont_supported is false.
(capture_main): Set vCont_supported to zero.
gdb/doc:
2015-09-15 Yao Qi <yao.qi@linaro.org>
* gdb.texinfo (General Query Packets): Add vContSupported to
tables of 'gdbfeatures' and 'stub features' supported in the
qSupported packet, as well as to the list containing stub
feature details.
In my patch https://sourceware.org/ml/gdb-patches/2015-04/msg01110.html
a new target_ops hook supports_conditional_breakpoints was added to
disable conditional breakpoints if target doesn't have hardware single
step. This patch is to generalize this hook from
supports_conditional_breakpoints to supports_hardware_single_step,
so that the following patch can use it.
gdb/gdbserver:
2015-09-15 Yao Qi <yao.qi@linaro.org>
* linux-low.c (linux_supports_conditional_breakpoints): Rename
it to ...
(linux_supports_hardware_single_step): ... New function.
(linux_target_ops): Update.
* lynx-low.c (lynx_target_ops): Set field
supports_hardware_single_step to target_can_do_hardware_single_step.
* nto-low.c (nto_target_ops): Likewise.
* spu-low.c (spu_target_ops): Likewise.
* win32-low.c (win32_target_ops): Likewise.
* target.c (target_can_do_hardware_single_step): New function.
* target.h (struct target_ops) <supports_conditional_breakpoints>:
Remove. <supports_hardware_single_step>: New field.
(target_supports_conditional_breakpoints): Remove.
(target_supports_hardware_single_step): New macro.
(target_can_do_hardware_single_step): Declare.
* server.c (handle_query): Use target_supports_hardware_single_step
instead of target_supports_conditional_breakpoints.
This patch is to fixup the siginfo_t when aarch64 gdb or gdbserver
read from or write to the arm inferior. It is to convert the
"struct siginfo_t" between aarch64 and arm, which is quite mechanical.
gdb/gdbserver:
2015-09-15 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_linux_siginfo_fixup): New
function.
(struct linux_target_ops the_low_target): Install
aarch64_linux_siginfo_fixup.
gdb:
2015-09-15 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (aarch64_linux_siginfo_fixup): New function.
(_initialize_aarch64_linux_nat): Call linux_nat_set_siginfo_fixup.
* nat/aarch64-linux.c (aarch64_compat_siginfo_from_siginfo):
New function.
(aarch64_siginfo_from_compat_siginfo): New function.
* nat/aarch64-linux.h: Include signal.h.
(compat_int_t, compat_uptr_t, compat_time_t): Typedef.
(compat_timer_t, compat_clock_t): Likewise.
(struct compat_timeval): New.
(union compat_sigval): New.
(struct compat_siginfo): New.
(cpt_si_pid, cpt_si_uid, cpt_si_timerid): New macros.
(cpt_si_overrun, cpt_si_status, cpt_si_utime): Likewise.
(cpt_si_stime, cpt_si_ptr, cpt_si_addr): Likewise.
(cpt_si_band, cpt_si_fd): Likewise.
This patch, relative to a tree with
https://sourceware.org/ml/gdb-patches/2015-08/msg00295.html, fixes
issues/crashes that trigger if something unexpected happens during a
hook-stop.
E.g., if the inferior disappears while running the hook-stop, we hit
failed assertions:
(gdb) define hook-stop
Type commands for definition of "hook-stop".
End with a line saying just "end".
>kill
>end
(gdb) si
Kill the program being debugged? (y or n) [answered Y; input not from terminal]
/home/pedro/gdb/mygit/build/../src/gdb/thread.c:88: internal-error: inferior_thread: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
I noticed that if a hook-stop issues a synchronous execution command,
we print the same stop event twice:
(gdb) define hook-stop
Type commands for definition of "hook-stop".
End with a line saying just "end".
>si
>end
(gdb) si
0x000000000040074a 42 args[i] = 1; /* Init value. */ <<<<<<< once
0x000000000040074a 42 args[i] = 1; /* Init value. */ <<<<<<< twice
(gdb)
In MI:
*stopped,reason="end-stepping-range",frame={addr="0x000000000040074a",func="main",args=[],file="threads.c",fullname="/home/pedro/gdb/tests/threads.c",line="42"},thread-id="1",stopped-threads="all",core="0"
*stopped,reason="end-stepping-range",frame={addr="0x000000000040074a",func="main",args=[],file="threads.c",fullname="/home/pedro/gdb/tests/threads.c",line="42"},thread-id="1",stopped-threads="all",core="0"
(gdb)
The fix has GDB stop processing the event if the context changed. I
don't expect people to be doing crazy things from the hook-stop.
E.g., it gives me headaches to try to come up a proper behavior for
handling a thread change from a hook-stop... (E.g., imagine the
hook-stop does thread N; step, with scheduler-locing on). I think the
most important bit here is preventing crashes.
The patch adds a new hook-stop.exp test that covers the above and also
merges in the old hook-stop-continue.exp and hook-stop-frame.exp into
the same framework.
gdb/ChangeLog:
2015-09-14 Pedro Alves <palves@redhat.com>
* infrun.c (current_stop_id): New global.
(get_stop_id, new_stop_id): New functions.
(fetch_inferior_event): Handle normal_stop proceeding the target.
(struct stop_context): New.
(save_stop_context, release_stop_context_cleanup)
(stop_context_changed): New functions.
(normal_stop): Return true if the hook-stop changes the stop
context.
* infrun.h (get_stop_id): Declare.
(normal_stop): Now returns int. Add documentation.
gdb/testsuite/ChangeLog:
2015-09-14 Pedro Alves <palves@redhat.com>
* gdb.base/hook-stop-continue.c: Delete.
* gdb.base/hook-stop-continue.exp: Delete.
* gdb.base/hook-stop-frame.c: Delete.
* gdb.base/hook-stop-frame.exp: Delete.
* gdb.base/hook-stop.c: New file.
* gdb.base/hook-stop.exp: New file.
This change is relevant only for standard DWARF (as opposed to the GNAT
encodings extensions): at the time of writing it only makes a difference
with GCC patches that are to be integrated: see in particular
<https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01364.html>.
Given the following Ada declarations:
type Small is mod 2 ** 6;
type Array_Type is array (0 .. 9) of Small
with Pack;
type Array_Access is access all Array_Type;
A : aliased Array_Type := (1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
AA : constant Array_Type := A'Access;
Before this change, we would get the following GDB session:
(gdb) print aa.all(2)
$1 = 3
(gdb) print aa(2)
$2 = 16
This is wrong: both expression should yield the same value: 3. The
problem is simply that the routine which handles accesses to arrays lack
general handling for packed arrays. After this patch, we have the
expected output:
(gdb) print aa.all(2)
$1 = 3
(gdb) print aa(2)
$2 = 3
gdb/ChangeLog:
* ada-lang.c (ada_value_ptr_subscript): Update the heading
comment. Handle packed arrays.
gdb/testsuite/ChangeLog:
* gdb.ada/access_to_packed_array.exp: New testcase.
* gdb.ada/access_to_packed_array/foo.adb: New file.
* gdb.ada/access_to_packed_array/pack.adb: New file.
* gdb.ada/access_to_packed_array/pack.ads: New file.
Tested on x86_64-linux, no regression.
Commit fbea99ea8a added this to both the "Changes in GDB 7.10" and
"Changes since GDB 7.10" sections by mistake.
gdb/ChangeLog:
2015-09-14 Pedro Alves <palves@redhat.com>
* NEWS (Changes in GDB 7.10, New commands>: Remove duplicate
mention of maint set/show target-non-stop.
The gdb.btrace/buffer-size.exp test starts recording with an unlimited
buffer size. This will, for a short time, use up most if not all BTS
resources.
I don' think this test is necessary. Remove it.
testsuite/
* gdb.btrace/buffer-size.exp: Remove recording with unlimited BTS
buffer size test.
This patch adds documentation of support for exec events on
extended-remote Linux targets.
gdb/ChangeLog:
* NEWS: Announce new remote packets for the exec-events
feature and the exec-events feature and associated commands.
gdb/doc/ChangeLog:
* gdb.texinfo (Remote Configuration): Add exec event
feature to table of packet settings.
(Stop Reply Packets): Add exec events to the list of stop
reasons.
(General Query Packets): Add exec events to tables of
'gdbfeatures' and 'stub features' supported in the qSupported
packet, as well as to the list containing stub feature
details.
This patch updates several exec-related tests and some of the library
functions in order to get them running with extended-remote. There were
three changes that were required, as follows:
In gdb.base/foll-exec.exp, use 'clean_start' in place of proc 'zap_session'
to reset the state of the debugger between tests. This sets 'remote
exec-file' to execute the correct binary file in each subsequent test.
In gdb.base/pie-execl.exp, there is an expect statement with an expression
that is used to match output from both gdb and the program under debug.
For the remote target, this had to be split into two expressions, using
$inferior_spawn_id to match the output from the program.
Because I had encountered problems with extended-remote exec events in
non-stop mode in my manual testing, I added non-stop testing to the
non-ldr-exc-[1234].exp tests. In order to set non-stop mode for remote
targets, it is necessary to 'set non-stop on' after gdb has started, but
before it connects to gdbserver. This is done using 'save_vars' to set
non-stop mode in GDBFLAGS, so GDB sets non-stop mode on startup.
gdb/testsuite/ChangeLog:
* gdb.base/foll-exec.c: Add copyright header. Fix
formatting issues.
* gdb.base/foll-exec.exp (zap_session): Delete proc.
(do_exec_tests): Use clean_restart in place of zap_session,
and for test initialization. Fix formatting issues. Use
fail in place of perror.
* gdb.base/pie-execl.exp (main): Use 'inferior_spawn_id' in
an expect statement to match an expression with output from
the program under debug.
* gdb.threads/non-ldr-exc-1.exp (do_test, main): Add
non-stop tests and pass stop mode argument to clean_restart.
Use save_vars to enable non-stop in GDBFLAGS.
* gdb.threads/non-ldr-exc-2.exp: Likewise.
* gdb.threads/non-ldr-exc-3.exp: Likewise.
* gdb.threads/non-ldr-exc-4.exp: Likewise.
This patch implements exec catchpoints for extended-remote Linux
targets. The implementation follows the same approach used for
fork catchpoints, implementing extended-remote target routines for
inserting and removing the catchpoints by just checking if exec events
are supported. Existing host-side code and previous support for
extended-remote exec events takes care of the rest.
gdb/ChangeLog:
* remote.c (remote_exec_event_p): New function.
(remote_insert_exec_catchpoint): New function.
(remote_remove_exec_catchpoint): New function.
(init_extended_remote_ops): Initialize extended_remote_ops
members to_insert_exec_catchpoint and
to_remove_exec_catchpoint.
This patch implements support for exec events on extended-remote Linux
targets. Follow-exec-mode and rerun behave as expected. Catchpoints and
test updates are implemented in subsequent patches.
This patch was derived from a patch posted last October:
https://sourceware.org/ml/gdb-patches/2014-10/msg00877.html.
It was originally based on some work done by Luis Machado in 2013.
IMPLEMENTATION
----------------
Exec events are enabled via ptrace options.
When an exec event is detected by gdbserver, the existing process
data, along with all its associated lwp and thread data, is deleted
and replaced by data for a new single-threaded process. The new
process data is initialized with the appropriate parts of the state
of the execing process. This approach takes care of several potential
pitfalls, including:
* deleting the data for an execing non-leader thread before any
wait/sigsuspend occurs
* correctly initializing the architecture of the execed process
We then report the exec event using a new RSP stop reason, "exec".
When GDB receives an "exec" event, it saves the status in the event
structure's target_waitstatus field, like what is done for remote fork
events. Because the original and execed programs may have different
architectures, we skip parsing the section of the stop reply packet
that contains register data. The register data will be retrieved
later after the inferior's architecture has been set up by
infrun.c:follow_exec.
At that point the exec event is handled by the existing event handling
in GDB. However, a few changes were necessary so that
infrun.c:follow_exec could accommodate the remote target.
* Where follow-exec-mode "new" is handled, we now call
add_inferior_with_spaces instead of add_inferior with separate calls
to set up the program and address spaces. The motivation for this
is that add_inferior_with_spaces also sets up the initial architecture
for the inferior, which is needed later by target_find_description
when it calls target_gdbarch.
* We call a new target function, target_follow_exec. This function
allows us to store the execd_pathname in the inferior, instead of
using the static string remote_exec_file from remote.c. The static
string didn't work for follow-exec-mode "new", since once you switched
to the execed program, the original remote exec-file was lost. The
execd_pathname is now stored in the inferior's program space as a
REGISTRY field. All of the requisite mechanisms for this are
defined in remote.c.
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_mourn): Static declaration.
(linux_arch_setup): Move in front of
handle_extended_wait.
(linux_arch_setup_thread): New function.
(handle_extended_wait): Handle exec events. Call
linux_arch_setup_thread. Make event_lwp argument a
pointer-to-a-pointer.
(check_zombie_leaders): Do not check stopped threads.
(linux_low_ptrace_options): Add PTRACE_O_TRACEEXEC.
(linux_low_filter_event): Add lwp and thread for exec'ing
non-leader thread if leader thread has been deleted.
Refactor code into linux_arch_setup_thread and call it.
Pass child lwp pointer by reference to handle_extended_wait.
(linux_wait_for_event_filtered): Update comment.
(linux_wait_1): Prevent clobbering exec event status.
(linux_supports_exec_events): New function.
(linux_target_ops) <supports_exec_events>: Initialize new member.
* lynx-low.c (lynx_target_ops) <supports_exec_events>: Initialize
new member.
* remote-utils.c (prepare_resume_reply): New stop reason 'exec'.
* server.c (report_exec_events): New global variable.
(handle_query): Handle qSupported query for exec-events feature.
(captured_main): Initialize report_exec_events.
* server.h (report_exec_events): Declare new global variable.
* target.h (struct target_ops) <supports_exec_events>: New
member.
(target_supports_exec_events): New macro.
* win32-low.c (win32_target_ops) <supports_exec_events>:
Initialize new member.
gdb/ChangeLog:
* infrun.c (follow_exec): Use process-style ptid for
exec message. Call add_inferior_with_spaces and
target_follow_exec.
* nat/linux-ptrace.c (linux_supports_traceexec): New function.
* nat/linux-ptrace.h (linux_supports_traceexec): Declare.
* remote.c (remote_pspace_data): New static variable.
(remote_pspace_data_cleanup): New function.
(get_remote_exec_file): New function.
(set_remote_exec_file_1): New function.
(set_remote_exec_file): New function.
(show_remote_exec_file): New function.
(remote_exec_file): Delete static variable.
(anonymous enum) <PACKET_exec_event_feature> New
enumeration constant.
(remote_protocol_features): Add entry for exec-events feature.
(remote_query_supported): Add client side of qSupported query
for exec-events feature.
(remote_follow_exec): New function.
(remote_parse_stop_reply): Handle 'exec' stop reason.
(extended_remote_run, extended_remote_create_inferior): Call
get_remote_exec_file and set_remote_exec_file_1.
(init_extended_remote_ops) <to_follow_exec>: Initialize new
member.
(_initialize_remote): Call
register_program_space_data_with_cleanup. Call
add_packet_config_cmd for remote exec-events feature.
Modify call to add_setshow_string_noescape_cmd for exec-file
to use new functions set_remote_exec_file and
show_remote_exec_file.
* target-debug.h, target-delegates.c: Regenerated.
* target.c (target_follow_exec): New function.
* target.h (struct target_ops) <to_follow_exec>: New member.
(target_follow_exec): Declare new function.
gdb/ChangeLog:
* aarch64-tdep.c (decode_cb): Move up comment describing the
encoding.
(decode_tb): Fix a typo in comment above the function. Move up
comment describing the encoding.
The encoding of the b.cond instruction is described in the architecture
reference manual as:
b.cond 0101 0100 iiii iiii iiii iiii iii0 cccc
So the mask should be 0xff000010.
gdb/ChangeLog:
* aarch64-tdep.c (decode_bcond): Fix incorrect mask.
I found this const/not const mixup found by building in C++ mode.
gdb/ChangeLog:
* ada-lang.c (ada_search_struct_field): Constify parameters
and/or variables..
(xget_renaming_scope): Likewise.
(ada_is_redundant_range_encoding): Likewise.
(scan_discrim_bound): Likewise.
(to_fixed_range_type): Likewise.
Nowadays, GDB calls target_can_download_tracepoint at the entry of
download_tracepoint_locations, which is called by.
update_global_location_list. Sometimes, it is not needed to call
target_can_download_tracepoint at all because there is no tracepoint
created. In remote target, target_can_download_tracepoint send
qTStatus to the remote in order to know whether tracepoint can be
downloaded or not. This means some redundant qTStatus packets are
sent.
This patch is to teach GDB to call target_can_download_tracepoint
lazily, only on the moment there are tracepoint to download.
gdb.perf/single-step.exp (with a local patch to measure RSP packets)
shows the number of RSP packets is reduced because there is no
tracepoint at all, so GDB doesn't send qTStatus any more.
# of RSP packets
original patched
single-step rsp 1000 7000 6000
single-step rsp 2000 14000 12000
single-step rsp 3000 21000 18000
single-step rsp 4000 28000 24000
gdb:
2015-09-10 Yao Qi <yao.qi@linaro.org>
* breakpoint.c (download_tracepoint_locations): New local
can_download_tracepoint. Check the result of
target_can_download_tracepoint and save it in
can_download_tracepoint if there are tracepoints to download.
* linux-nat.h (enum tribool): Move it to ...
* common/common-types.h: ... here.
gdb/ChangeLog:
2015-09-09 Pedro Alves <palves@redhat.com>
* breakpoint.c: Include "thread-fsm.h".
(struct until_break_command_continuation_args): Delete.
(struct until_break_fsm): New.
(until_break_fsm_ops): New global.
(new_until_break_fsm, until_break_fsm_should_stop): New functions.
(until_break_command_continuation): Delete.
(until_break_fsm_clean_up): New function.
(until_break_fsm_async_reply_reason): New function.
(until_break_command): Adjust to create an until_break_fsm instead
of a continuation.
(momentary_bkpt_print_it): No longer print MI's async-stop-reason
here.
* infcmd.c (struct until_next_fsm): New.
(until_next_fsm_ops): New global.
(new_until_next_fsm, until_next_fsm_should_stop): New function.
(until_next_continuation): Delete.
(until_next_fsm_clean_up, until_next_fsm_async_reply_reason): New
functions.
(until_next_command): Adjust to create a new until_next_fsm
instead of a continuation.
This removes infcall-specific special casing from normal_stop,
simplifying it.
Like the "finish" command's, the FSM is responsible for storing the
function's return value.
gdb/ChangeLog:
2015-09-09 Pedro Alves <palves@redhat.com>
* infcall.c: Include thread_fsm.h.
(struct call_return_meta_info): New.
(get_call_return_value): New function, factored out from
call_function_by_hand_dummy.
(struct call_thread_fsm): New.
(call_thread_fsm_ops): New global.
(new_call_thread_fsm, call_thread_fsm_should_stop)
(call_thread_fsm_should_notify_stop): New functions.
(run_inferior_call): Add 'sm' parameter. Associate the FSM with
the thread.
(call_function_by_hand_dummy): Create a new call_thread_fsm
instance, associate it with the thread, and wait for the FSM to
finish. If finished successfully, fetch the function's result
value out of the FSM.
* infrun.c (fetch_inferior_event): If the FSM says the stop
shouldn't be notified, don't call normal_stop.
(maybe_remove_breakpoints): New function, factored out from ...
(normal_stop): ... here. Simplify.
* infrun.h (maybe_remove_breakpoints): Declare.
* thread-fsm.c (thread_fsm_should_notify_stop): New function.
(thread-fsm.h) <struct thread_fsm_ops>: New field.
(thread_fsm_should_notify_stop): Declare.
This adds an object oriented replacement for the "struct continuation"
mechanism, and converts the stepping commands (step, next, stepi,
nexti) and the "finish" commands to use it.
It adds a new thread "class" (struct thread_fsm) that contains the
necessary info and callbacks to manage the state machine of a thread's
execution command.
This allows getting rid of some hacks. E.g., in fetch_inferior_event
and normal_stop we no longer need to know whether a thread is doing a
multi-step (e.g., step N). This effectively makes the
intermediate_continuations unused -- they'll be garbage collected in a
separate patch. (They were never a proper abstraction, IMO. See how
fetch_inferior_event needs to check step_multi before knowing whether
to call INF_EXEC_CONTINUE or INF_EXEC_COMPLETE.)
The target async vs !async uiout hacks in mi_on_normal_stop go away
too.
print_stop_event is no longer called from normal_stop. Instead it is
now called from within each interpreter's normal_stop observer. This
clears the path to make each interpreter print a stop event the way it
sees fit. Currently we have some hacks in common code to
differenciate CLI vs TUI vs MI around this area.
The "finish" command's FSM class stores the return value plus that
value's position in the value history, so that those can be printed to
both MI and CLI's streams. This fixes the CLI "finish" command when
run from MI -- it now also includes the function's return value in the
CLI stream:
(gdb)
~"callee3 (strarg=0x400730 \"A string argument.\") at src/gdb/testsuite/gdb.mi/basics.c:35\n"
~"35\t}\n"
+~"Value returned is $1 = 0\n"
*stopped,reason="function-finished",frame=...,gdb-result-var="$1",return-value="0",thread-id="1",stopped-threads="all",core="0"
-FAIL: gdb.mi/mi-cli.exp: CLI finish: check CLI output
+PASS: gdb.mi/mi-cli.exp: CLI finish: check CLI output
gdb/ChangeLog:
2015-09-09 Pedro Alves <palves@redhat.com>
* Makefile.in (COMMON_OBS): Add thread-fsm.o.
* breakpoint.c (handle_jit_event): Print debug output.
(bpstat_what): Split event callback handling to ...
(bpstat_run_callbacks): ... this new function.
(momentary_bkpt_print_it): No longer handle bp_finish here.
* breakpoint.h (bpstat_run_callbacks): Declare.
* gdbthread.h (struct thread_info) <step_multi>: Delete field.
<thread_fsm>: New field.
(thread_cancel_execution_command): Declare.
* infcmd.c: Include thread-fsm.h.
(struct step_command_fsm): New.
(step_command_fsm_ops): New global.
(new_step_command_fsm, step_command_fsm_prepare): New functions.
(step_1): Adjust to use step_command_fsm_prepare and
prepare_one_step.
(struct step_1_continuation_args): Delete.
(step_1_continuation): Delete.
(step_command_fsm_should_stop): New function.
(step_once): Delete.
(step_command_fsm_clean_up, step_command_fsm_async_reply_reason)
(prepare_one_step): New function, based on step_once.
(until_next_command): Remove step_multi reference.
(struct return_value_info): New.
(print_return_value): Rename to ...
(print_return_value_1): ... this. New struct return_value_info
parameter. Adjust.
(print_return_value): Reimplement as wrapper around
print_return_value_1.
(struct finish_command_fsm): New.
(finish_command_continuation): Delete.
(finish_command_fsm_ops): New global.
(new_finish_command_fsm, finish_command_fsm_should_stop): New
functions.
(finish_command_fsm_clean_up, finish_command_fsm_return_value):
New.
(finish_command_continuation_free_arg): Delete.
(finish_command_fsm_async_reply_reason): New.
(finish_backward, finish_forward): Change symbol parameter to a
finish_command_fsm. Adjust.
(finish_command): Create a finish_command_fsm. Adjust.
* infrun.c: Include "thread-fsm.h".
(clear_proceed_status_thread): Delete the thread's FSM.
(infrun_thread_stop_requested_callback): Cancel the thread's
execution command.
(clean_up_just_stopped_threads_fsms): New function.
(fetch_inferior_event): Handle the event_thread's should_stop
method saying the command isn't done yet.
(process_event_stop_test): Run breakpoint callbacks here.
(print_stop_event): Rename to ...
(print_stop_location): ... this.
(restore_current_uiout_cleanup): New function.
(print_stop_event): Reimplement.
(normal_stop): No longer notify the end_stepping_range observers
here handle "step N" nor "finish" here. No longer call
print_stop_event here.
* infrun.h (struct return_value_info): Forward declare.
(print_return_value): Declare.
(print_stop_event): Change prototype.
* thread-fsm.c: New file.
* thread-fsm.h: New file.
* thread.c: Include "thread-fsm.h".
(thread_cancel_execution_command): New function.
(clear_thread_inferior_resources): Call it.
* cli/cli-interp.c (cli_on_normal_stop): New function.
(cli_interpreter_init): Install cli_on_normal_stop as normal_stop
observer.
* mi/mi-interp.c: Include "thread-fsm.h".
(restore_current_uiout_cleanup): Delete.
(mi_on_normal_stop): If the thread has an FSM associated, and it
finished, ask it for the async-reply-reason to print. Always call
print_stop_event here, regardless of the top-level interpreter.
Check bpstat_what to tell whether an asynchronous breakpoint hit
triggered.
* tui/tui-interp.c (tui_on_normal_stop): New function.
(tui_init): Install tui_on_normal_stop as normal_stop observer.
gdb/testsuite/ChangeLog:
2015-09-09 Pedro Alves <palves@redhat.com>
* gdb.mi/mi-cli.exp: Add CLI finish tests.
This patch makes the execution control code use largely the same
mechanisms in both sync- and async-capable targets. This means using
continuations and use the event loop to react to target events on sync
targets as well. The trick is to immediately mark infrun's event loop
source after resume instead of calling wait_for_inferior. Then
fetch_inferior_event is adjusted to do a blocking wait on sync
targets.
Tested on x86_64 Fedora 20, native and gdbserver, with and without
"maint set target-async off".
gdb/ChangeLog:
2015-09-09 Pedro Alves <palves@redhat.com>
* breakpoint.c (bpstat_do_actions_1, until_break_command): Don't
check whether the target can async.
* inf-loop.c (inferior_event_handler): Only call target_async if
the target can async.
* infcall.c: Include top.h and interps.h.
(run_inferior_call): For the interpreter to sync mode while
running the infcall. Call wait_sync_command_done instead of
wait_for_inferior plus normal_stop.
* infcmd.c (prepare_execution_command): Don't check whether the
target can async when running in the foreground.
(step_1): Delete synchronous case handling.
(step_once): Always install a continuation, even in sync mode.
(until_next_command, finish_forward): Don't check whether the
target can async.
(attach_command_post_wait, notice_new_inferior): Always install a
continuation, even in sync mode.
* infrun.c (mark_infrun_async_event_handler): New function.
(proceed): In sync mode, mark infrun's event source instead of
waiting for events here.
(fetch_inferior_event): If the target can't async, do a blocking
wait.
(prepare_to_wait): In sync mode, mark infrun's event source.
(infrun_async_inferior_event_handler): No longer bail out if the
target can't async.
* infrun.h (mark_infrun_async_event_handler): New declaration.
* linux-nat.c (linux_nat_wait_1): Remove calls to
set_sigint_trap/clear_sigint_trap.
(linux_nat_terminal_inferior): No longer check whether the target
can async.
* mi/mi-interp.c (mi_on_sync_execution_done): Update and simplify
comment.
(mi_execute_command_input_handler): No longer check whether the
target is async. Update and simplify comment.
* target.c (default_target_wait): New function.
* target.h (struct target_ops) <to_wait>: Now defaults to
default_target_wait.
(default_target_wait): Declare.
* top.c (wait_sync_command_done): New function, factored out from
...
(maybe_wait_sync_command_done): ... this.
* top.h (wait_sync_command_done): Declare.
* target-delegates.c: Regenerate.
For the BTS recording format, we sometimes get a FROM->TO record where the
FROM address lies in the kernel and the TO address lies in user space at
whatever address the user process was resumed.
GDB has a heuristic to filter out such records based on looking at the most
significant bit in the PC. This works fine for 64-bit systems but it doesn't
always work for 32-bit systems. Libraries that are loaded at fairly high
addresses might be mistaken for kernel code and branches inside the library
are filtered out.
Change the heuristic to (again heuristically) try to determine the lowest
address in kernel space. Any PC that is smaller than that should be in
user space.
On today's systems, there should be a symbol "_text" at that address.
Read /proc/kallsyms and search for that symbol.
It is not guaranteed that /proc/kallsyms is readable on all systems. On
64-bit systems, we fall back to check the most significant bit. On 32-bit
systems, we refrain from filtering out addresses.
The filtering should really be done by the kernel. And it soon will be:
https://lkml.org/lkml/2015/8/31/212.
gdb/
* nat/linux-btrace.h (struct btrace_target_info) <ptr_bits>: Remove.
* nat/linux-btrace.c: Include filestuff.h and inttypes.h.
Remove include of sys/utsname.h.
(linux_determine_kernel_ptr_bits): Remove.
(linux_determine_kernel_start): New.
(perf_event_is_kernel_addr): Remove tinfo argument. Update users.
Update check.
(perf_event_skip_bts_record): Remove tinfo argument. Update users.
(linux_enable_bts, linux_enable_pt): Remove tinfo->ptr_bits
initialization.
* x86-linux-nat.c (x86_linux_enable_btrace): Remove ptr_bits
assignment.
gdbserver/
* linux-low.c (linux_low_enable_btrace): Remove.
(linux_target_ops): Replace linux_low_enable_btrace with
linux_enable_btrace.
2015-09-08 Sandra Loosemore <sandra@codesourcery.com>
gdb/testsuite/
* gdb.threads/hand-call-in-threads.exp: Make sure the thread
command actually switches threads. Give up on remaining
tests if target fails to stop at breakpoint.
Building GDB in C++ mode on Fedora 20, the gdb/guile/ code shows ~280
errors like:
src/gdb/guile/guile.c:515:1: error: invalid conversion from ‘scm_unused_struct* (*)(SCM, SCM) {aka scm_unused_struct* (*)(scm_unused_struct*, scm_unused_struct*)}’ to ‘scm_t_subr {aka void*}’ [-fpermissive]
This commit fixes them all.
gdb/ChangeLog:
2015-09-07 Pedro Alves <palves@redhat.com>
* guile/guile-internal.h (as_a_scm_t_subr): New.
* guile/guile.c (misc_guile_functions): Use it.
* guile/scm-arch.c (arch_functions): Use it.
* guile/scm-block.c (block_functions, gdbscm_initialize_blocks):
Use it.
* guile/scm-breakpoint.c (breakpoint_functions): Use it.
* guile/scm-cmd.c (command_functions): Use it.
* guile/scm-disasm.c (disasm_functions): Use it.
* guile/scm-exception.c (exception_functions)
(private_exception_functions): Use it.
* guile/scm-frame.c (frame_functions)
* guile/scm-gsmob.c (gsmob_functions): Use it.
* guile/scm-iterator.c (iterator_functions): Use it.
* guile/scm-lazy-string.c (lazy_string_functions): Use it.
* guile/scm-math.c (math_functions): Use it.
* guile/scm-objfile.c (objfile_functions): Use it.
* guile/scm-param.c (parameter_functions): Use it.
* guile/scm-ports.c (port_functions, private_port_functions): Use
it.
* guile/scm-pretty-print.c (pretty_printer_functions): Use it.
* guile/scm-progspace.c (pspace_functions): Use it.
* guile/scm-string.c (string_functions): Use it.
* guile/scm-symbol.c (symbol_functions): Use it.
* guile/scm-symtab.c (symtab_functions): Use it.
* guile/scm-type.c (type_functions, gdbscm_initialize_types): Use
it.
* guile/scm-value.c (value_functions): Use it.
In the following code:
struct symbol *wsym = (struct symbol *) NULL;
the cast of NULL is redundant, it adds noise, and is just one more thing
to change if the type of wsym ever changes. There are a relatively
small number of places in gdb where the above code pattern is used.
Usually the cast is removed like this:
struct symbol *wsym = NULL;
This commit updates all the places within the gdb/tui directory where we
cast NULL during assignment, removing the cast.
gdb/ChangeLog:
* tui/tui-data.c (win_with_focus): Remove cast of NULL pointer.
(tui_next_win): Likewise.
(tui_prev_win): Likewise.
(tui_partial_win_by_name): Likewise.
(tui_init_generic_part): Likewise.
(init_content_element): Likewise.
(tui_del_window): Likewise.
(tui_free_window): Likewise.
(tui_del_data_windows): Likewise.
(tui_free_data_content): Likewise.
* tui/tui-layout.c (make_source_or_disasm_window): Likewise.
* tui/tui-regs.c (tui_show_register_group): Likewise.
* tui/tui-win.c (tui_resize_all): Likewise.
(tui_set_focus): Likewise.
(tui_set_win_height): Likewise.
(make_invisible_and_set_new_height): Likewise.
* tui/tui-windata.c (tui_delete_data_content_windows): Likewise.
* tui/tui-wingeneral.c (make_visible): Likewise.
In the following code:
struct symbol *wsym = (struct symbol *) NULL;
the cast of NULL is redundant, it adds noise, and is just one more thing
to change if the type of wsym ever changes. There are a relatively
small number of places in gdb where the above code pattern is used.
Usually the cast is removed like this:
struct symbol *wsym = NULL;
This commit updates all the places within the gdb/cli directory where we
cast NULL during assignment, removing the cast.
gdb/ChangeLog:
* cli/cli-decode.c (find_cmd): Remove cast of NULL pointer.
In the following code:
struct symbol *wsym = (struct symbol *) NULL;
the cast of NULL is redundant, it adds noise, and is just one more thing
to change if the type of wsym ever changes. There are a relatively
small number of places in gdb where the above code pattern is used.
Usually the cast is removed like this:
struct symbol *wsym = NULL;
This commit updates all the places within the gdb/ directory where we
cast NULL during assignment, removing the cast.
gdb/ChangeLog:
* c-valprint.c (print_unpacked_pointer): Remove cast of NULL
pointer.
* dbxread.c (dbx_end_psymtab): Likewise.
* gnu-nat.c (gnu_write_inferior): Likewise.
* mdebugread.c (cross_ref): Likewise.
* p-valprint.c (pascal_val_print): Likewise.
* xcoffread.c (xcoff_end_psymtab): Likewise.
Before this change, trying to call an overloaded function with at least
one character literal in argument would fail. For instance, given these
two functions:
function F (C : Character) return Integer is
begin
return Character'Pos (C);
end F;
function F (I : Integer) return Integer is
begin
return -I;
end F;
We would get the following GDB session:
(gdb) p f('A')
$1 = -65
(gdb) p f(1)
$1 = -1
This is wrong because the first call should select the first F function
and thus return 65.
The root problem is that ada-lang.c:ada_language_arch_info stores in
string_char_type a type whose code is TYPE_CODE_INT instead of
TYPE_CODE_CHAR. As a result, all parsed character literals are turned
into integer values and during overload matching, the TYPE_CODE_CHAR
formal rejects the TYPE_CODE_INT actual.
This change turns string_char_type into a true TYPE_CODE_CHAR type in
ada-lang.c so that we have instead the expected:
(gdb) p f('A')
$1 = 65
gdb/ChangeLog:
* ada-lang.c (ada_language_arch_info): Create a TYPE_CODE_CHAR
type instead of a TYPE_CODE_INT one for the string_char_type
and the ada_primitive_type_char types.
gdb/testsuite/ChangeLog:
* gdb.ada/funcall_char.exp: New testcase.
* gdb.ada/funcall_char/foo.adb: New file.
Tested on x86_64-linux, no regression.
Nowadays, if user requests HW watchpoint to monitor a large memory area
or unaligned area, aarch64 GDB will split into multiple aligned areas,
and use multiple debugging registers to watch them. However, the
registers are not updated in a transaction way. GDBserver doesn't revert
updates in previous iterations if some debugging registers fail to update
due to some reason, like no free debugging registers available, in the
latter iteration. For example, if we have a char buf[34], and watch buf
in gdb,
(gdb) watch buf
Hardware watchpoint 2: buf
(gdb) c
Continuing.
infrun: clear_proceed_status_thread (Thread 13466)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: step-over queue now empty
infrun: resuming [Thread 13466] for step-over
Sending packet: $m410838,22#35...Packet received: 00000000000000000000000000000000000000000000000000000000000000000000
infrun: skipping breakpoint: stepping past insn at: 0x400524
infrun: skipping breakpoint: stepping past insn at: 0x400524
Sending packet: $Z2,410838,22#80...Packet received: E01 <----- [1]
Packet Z2 (write-watchpoint) is supported
Sending packet: $Z0,7fb7fe0a8c,4#43...Packet received: OK
Warning:
Could not insert hardware watchpoint 2.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
GDB receives E01 for Z2 packet [1] but GDBserver updates the debugging
register status,
insert_point (addr=0x00410838, len=34, type=hw-write-watchpoint):
BREAKPOINTs:
BP0: addr=0x0, ctrl=0x00000000, ref.count=0
BP1: addr=0x0, ctrl=0x00000000, ref.count=0
BP2: addr=0x0, ctrl=0x00000000, ref.count=0
BP3: addr=0x0, ctrl=0x00000000, ref.count=0
BP4: addr=0x0, ctrl=0x00000000, ref.count=0
BP5: addr=0x0, ctrl=0x00000000, ref.count=0
WATCHPOINTs:
WP0: addr=0x410850, ctrl=0x00001ff5, ref.count=1
WP1: addr=0x410848, ctrl=0x00001ff5, ref.count=1
WP2: addr=0x410840, ctrl=0x00001ff5, ref.count=1
WP3: addr=0x410838, ctrl=0x00001ff5, ref.count=1
four debugging registers can not monitor 34-byte long area, so the last
iteration of updating debugging register state fails but previous
iterations succeed. This makes GDB think no HW watchpoint is inserted
but some debugging registers are used.
This problem was exposed by "watch buf" gdb.base/watchpoint.exp with
aarch64 GDBserver debugging arm 32-bit program. The buf is 30-byte long
but 4-byte aligned, and four debugging registers can't cover 34-byte
(extend 4 bytes to be 8-byte aligned) area. However, this problem
does exist on non-multi-arch debugging scenario as well.
This patch moves code in aarch64_linux_region_ok_for_hw_watchpoint to
aarch64_linux_region_ok_for_watchpoint in nat/aarch64-linux-hw-point.c.
Then, checks with aarch64_linux_region_ok_for_watchpoint, like what we
are doing in GDB. If the region is OK, call aarch64_handle_watchpoint.
Regression tested on aarch64 with both 64-bit program and 32-bit
program. Some fails in gdb.base/watchpoint.exp are fixed.
gdb:
2015-09-03 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (aarch64_linux_region_ok_for_hw_watchpoint):
Move code to aarch64_linux_region_ok_for_watchpoint. Call
aarch64_linux_region_ok_for_watchpoint.
* nat/aarch64-linux-hw-point.c (aarch64_linux_region_ok_for_watchpoint):
New function.
* nat/aarch64-linux-hw-point.h (aarch64_linux_region_ok_for_watchpoint):
Declare it.
gdb/gdbserver:
2015-09-03 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_insert_point): Call
aarch64_handle_watchpoint if aarch64_linux_region_ok_for_watchpoint
returns true.
Since the type whose name is being set is now being allocated on the
gdbarch obstack, we should allocate its TYPE_NAME on the obstack too.
This reduces the number of individual valgrind warnings for the command
"gdb gdb" from ~300 to ~150.
Tested on x86_64-unknown-linux-gnu.
gdb/ChangeLog:
* gdb_obstack.h (obstack_strdup): Declare.
* gdb_obstack.c (obstack_strdup): Define.
* gdbarch.sh (gdbarch_obstack_strdup): Declare and define.
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbtypes.c (arch_type): Use gdbarch_obstack_strdup.
Following commit 8f57eec2fb ("Use gdbarch obstack to allocate types in
alloc_type_arch") it is no longer the case that the type returned by
copy_type_recursive is allocated using malloc. Because the function
uses alloc_type_arch internally, the new type is now allocated on the
gdbarch associated with the type, and is thus owned by that gdbarch.
gdb/ChangeLog:
* gdbtypes.c (copy_type_recursive): Update documentation.
Yet another BuildBot e-mail, yet another breakage on RHEL-7.1 s390x
(which uses an older GCC). This time,
solib-svr4.c:solib_event_probe_action has the probe_argc variable,
which is now inside a TRY..CATCH and therefore needs to be
initialized. Pushed as obvious.
gdb/ChangeLog:
2015-09-01 Sergio Durigan Junior <sergiodj@redhat.com>
* solib-svr4.c (solib_event_probe_action): Initialize 'probe_argc'
as zero.
BuildBot e-mailed me to let me know that my last commit broke GDB on
RHEL-7.1 s390x. On solib-svr4.c:svr4_handle_solib_event, 'val' now
needs to be initialized as NULL because it is inside a TRY..CATCH
block. This patch does that. Pushed as obvious.
gdb/ChangeLog:
2015-09-01 Sergio Durigan Junior <sergiodj@redhat.com>
* solib-svr4.c (svr4_handle_solib_event): Initialize 'val' as NULL
This patch is intended to make the interaction between the
probes-based dynamic linker interface and the SystemTap SDT probe code
on GDB more robust. It does that by wrapping the calls to the probe
API with TRY...CATCH'es, so that any exception thrown will be caught
and handled properly.
The idea for this patch came from
<https://bugzilla.redhat.com/show_bug.cgi?id=1196181>, which is a bug
initially filed against Fedora GDB (but now under Fedora GLIBC). This
bug happens on armhfp (although it could happen on other targets as
well), and is triggered because GCC generates a strange argument for
one of the probes used by GDB in the dynamic linker interface. As can
be seen in the bug, this argument is "-4@.L1052".
I don't want to discuss the reasons for this argument to be there
(this discussion belongs to the bug, or to another thread), but GDB
could definitely do a better error handling here. Currently, one sees
the following message when there is an error in the probes-based
dynamic linker interface:
(gdb) run
Starting program: /bin/inferior
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
Cannot parse expression `.L976 4@r4'.
(gdb)
Which means that one needs to explicitly issue a "continue" command to
make GDB continue running the inferior, even though this error is not
fatal and GDB will fallback to the old interface automatically.
This is where this patch helps: it makes GDB still print the necessary
warnings or error messages, but it *also* does not stop the inferior
unnecessarily.
I have tested this patch on the systems where this error happens, but
I could not come up with a way to create a testcase for it.
Nevertheless, it should be straightforward to see that this patch does
improve the current situation.
gdb/ChangeLog:
2015-09-01 Sergio Durigan Junior <sergiodj@redhat.com>
* solib-svr4.c (solib_event_probe_action): Call
get_probe_argument_count using TRY...CATCH.
(svr4_handle_solib_event): Likewise, for evaluate_probe_argument.
This patch improves the error reporting when handling SystemTap SDT
probes. "Handling", in this case, mostly means "parsing".
On gdb/probe.h, only trivial changes on functions' comments in order
to explicitly mention that some of them can throw exceptions. This is
just to make the API a bit more clear.
On gdb/stap-probe.c, I have s/internal_error/error/ on two functions
that are responsible for parsing specific bits of the probes'
arguments: stap_get_opcode and stap_get_expected_argument_type. It is
not correct to call internal_error on such situations because it is
not really GDB's fault if the probes have malformed arguments. I also
improved the error reported on stap_get_expected_argument_type by also
including the probe name on it.
Aside from that, and perhaps most importantly, I added a check on
stap_get_arg to make sure that we don't try to extract an argument
from a probe that has no arguments. This check issues an
internal_error, because it really means that GDB is doing something it
shouldn't.
Although it can be considered almost trivial, and despite the fact
that I am the maintainer for this part of the code, I am posting this
patch for review. I will wait a few days, and if nobody has anything
to say, I will go ahead and push it.
gdb/ChangeLog:
2015-09-01 Sergio Durigan Junior <sergiodj@redhat.com>
* probe.h (struct probe_ops) <get_probe_argument_count,
evaluate_probe_argument, enable_probe, disable_probe>: Mention in
the comment that the function can throw an exception.
(get_probe_argument_count): Likewise.
(evaluate_probe_argument): Likewise.
* stap-probe.c (stap_get_opcode): Call error instead of
internal_error.
(stap_get_expected_argument_type): Likewise. Add argument
'probe'. Improve error message by mentioning the probe's name.
(stap_parse_probe_arguments): Adjust call to
stap_get_expected_argument_type.
(stap_get_arg): Add comment. Assert that 'probe->args_parsed' is
not zero. Call internal_error if GDB requests an argument but the
probe has no arguments.
Before this change, trying to complete an expression ending with an
ambiguous function name (i.e. for which there are multiple matches)
would display a menu with a prompt for the user to pick one. For
instance:
(gdb) p func<tab>Multiple matches for func
[0] cancel
[1] pack2.func at pack2.adb:5
[2] pack.func at pack.adb:5
>
This is not user friendly and actually triggered a segmentation fault
after the user did pick one. It is not clear whether the segmentation
fault needs a separate fix, but this is the only known case which
exhibits it at the moment, and this case must be fixed itself.
The problem lies in ada-lang.c (ada_resolve_function): when we got
multiple matches, we should not display the menu if we are in completion
mode. This patch adjusts the corresponding condition accordingly.
gdb/ChangeLog:
* ada-lang.c (ada_resolve_function): Do not ask the user what
match to use when in completion mode.
gdb/testsuite/ChangeLog:
* gdb.ada/complete.exp: Add "pck.ambiguous_func" to the relevant
expected outputs. Add two testcases for completing ambiguous
functions.
* gdb.ada/complete/aux_pck.adb: New file.
* gdb.ada/complete/aux_pck.ads: New file.
* gdb.ada/complete/foo.adb: Pull Aux_Pck and call the two
Ambiguous_Func functions.
* gdb.ada/complete/pck.ads: Add an Ambiguous_Func function.
* gdb.ada/complete/pck.adb: Likewise.
Tested on x86_64-linux, no regression.
Small clean up to make a local variable const and remove a cast of NULL.
gdb/ChangeLog:
* tui/tui-data.c (tui_win_name): Make local variable const, remove
cast of NULL.
Use XSHAL_ABI value provided by xtensa-config.h to correctly initialize
xtensa_tdep.call_abi
This fixes calls to functions from GDB that otherwise fail with the
following assertion in call0 configuration:
gdb/regcache.c:602: internal-error: regcache_raw_read: Assertion
`regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed.
2015-08-31 Max Filippov <jcmvbkbc@gmail.com>
gdb/
* xtensa-tdep.h (XTENSA_GDBARCH_TDEP_INSTANTIATE): Initialize
call_abi using XSHAL_ABI macro.
Since the type whose name is being set is now being allocated on the
gdbarch obstack, we should allocate its TYPE_NAME on the obstack too.
This reduces the number of individual valgrind warnings for the command
"gdb gdb" from ~300 to ~150.
Tested on x86_64-unknown-linux-gnu.
gdb/ChangeLog:
* gdbarch.h (gdbarch_obstack_strdup): Declare.
* gdbarch.c (gdbarch_obstack_strdup): Define.
* gdbtypes.c (arch_type): Use it.
For the command "gdb gdb" valgrind currently reports 100s of individual
memory leaks, 500 of which originate solely out of the function
alloc_type_arch. This function allocates a "struct type" associated
with the given gdbarch using malloc but apparently the types allocated
by this function are never freed.
This patch fixes these leaks by making the function alloc_type_arch
allocate these gdbarch-associated types on the gdbarch obstack instead
of on the general heap. Since, from what I can tell, the types
allocated by this function are all fundamental "wired-in" types, such
types would not benefit from more granular memory management anyway.
They would likely live as long as the gdbarch is alive so allocating
them on the gdbarch obstack makes sense.
With this patch, the number of individual vargrind warnings emitted for
the command "gdb gdb" drops from ~800 to ~300.
Tested on x86_64-unknown-linux-gnu.
gdb/ChangeLog:
* gdbtypes.c (alloc_type_arch): Allocate the type on the given
gdbarch obstack instead of on the heap. Update commentary
accordingly.
solib_ops are installed as a property of the inferior gdbarch,
so they need to be systematically looked up via that architecture,
not some objfile architecture.
ChangeLog:
Revert:
2014-11-06 Doug Evans <xdje42@gmail.com>
* solib.c (solib_global_lookup): Fetch arch from objfile,
not target_gdbarch.
When debugging Cell/B.E. code, the cross-architecture frame unwinding
works by accessing data structures refered to by a thread-local variable
in the inferior. While accessing this variable via minimal symbol,
code would use BMSYMBOL_VALUE_ADDRESS to determine the offset of the
variable in the thread-local storage block.
This is incorrect, since it adds any relocation offset of the shared
library defining the TLS variable. That offset would be OK when
accessing the initial copy present in the .tbss section, but it must
not be applied to the offset of the variable in the TLS block at
runtime. Depending on whether or not the libspe2.so library was
prelinked, access to the variable would fail due to the incorrectly
relocated offset.
ChangeLog:
* ppc-linux-tdep.c (ppc_linux_spe_context_lookup): Do not
attempt to relocate a TLS variable offset.
With recent changes to inferior handling, parse_spufs_run needs to be
more careful in assumptions it makes. In particular, this patch:
- Bails out early if the current inferior has not yet been registered
(e.g. during fork procession) to avoid assertion failures in register
cache code.
- Sets inferior_ptid to the current ptid while calling target_read_memory
to make sure the correct process is accessed if parse_spufs_run is
called early when inferior_ptid has not yet been switched by the caller.
ChangeLog:
* spu-multiarch.c (parse_spufs_run): Bail out if inferior is not
registered yet. Set inferior_ptid while calling target_read_memory.
The Linux target and gdbserver now check the siginfo si_code
reported on a SIGTRAP to detect whether the trap indicates
a software breakpoint was hit.
Unfortunately, on Cell/B.E., the kernel uses an si_code value
of TRAP_BRKPT when a SW breakpoint was hit in PowerPC code,
but a si_code value of SI_KERNEL when a SW breakpoint was
hit in SPU code.
This patch updates Linux target and gdbserver to accept both
si_code values to indicate SW breakpoint on PowerPC.
ChangeLog:
* nat/linux-ptrace.h (GDB_ARCH_TRAP_BRKPT): Replace by ...
(GDB_ARCH_IS_TRAP_BRKPT): ... this. Add __powerpc__ case.
* linux-nat.c (check_stopped_by_breakpoint): Use
GDB_ARCH_IS_TRAP_BRKPT instead of GDB_ARCH_TRAP_BRKPT.
gdbserver/ChangeLog:
* linux-low.c (check_stopped_by_breakpoint): Use
GDB_ARCH_IS_TRAP_BRKPT instead of GDB_ARCH_TRAP_BRKPT.
Since we are no longer using thread events by default in linux-thread-db,
the find_new_threads_once routine contains an assertion that it should
never be called on a live inferior unless using thread events:
gdb_assert (!target_has_execution || thread_db_use_events ());
However, there is a code path from thread_db_get_thread_local_address
that will in fact call find_new_threads_once in some scenarios. In
particular, this is currently always triggered when starting up any
Cell/B.E. combined exeuctable.
To fix this, this patch removes the call to thread_db_find_new_threads_1
when the current thread was not yet detected. In its place, we now just
call thread_from_lwp to detect this one thread if necessary.
ChangeLog:
* linux-thread-db.c (thread_db_get_thread_local_address): If the
thread was not yet discovered, use thread_from_lwp instead of
calling thread_db_find_new_threads_1.
The gdb.cell testcases use the predicate skip_cell_tests defined in
lib/cell.exp to determine whether Cell/B.E. test cases ought to be
run. This tests verifies that we have a toolchain that supports
generating combined Cell/B.E. binaries, and that the target machine
actually is a Cell/B.E.
In order to do so, a small test program is built and run (under the
debugger). Any failure is taken as a sign that we don't have a
Cell/B.E. machine and the tests are to be skipped.
This has the unfortunate effect that a serious bug in GDB that causes
internal compiler errors even on the trivial test program does not
lead to any failures in the testsuite, since now all gdb.cell test
are simply skipped.
This patch changes skip_cell_tests to at least report UNRESOLVED
in cases where execution of the test program fails in unexpected
ways.
testsuite/ChangeLog:
* lib/cell.exp (skip_cell_tests): Report UNRESOLVED on unexpected
failures to run the test program under GDB.
These two statements were inverted by mistake in commit "Replace some
xmalloc-family functions with XNEW-family ones". It obviously doesn't
make sense to have them in this order, which is why I am pushing this as
obvious.
gdb/ChangeLog:
* m88k-tdep.c (m88k_analyze_prologue): Fix inverted allocation
statements.
I think it would be a good idea to document that gdb now has (basic)
support to read/write memory on architectures with non-8-bits memory.
Hopefully somebody will see it and say "Hey! We can now (more easily)
port GDB to our strange DSP that has 32-bits-addressable memory!" and do
it.
gdb/ChangeLog:
* NEWS: Document support for non-8-bits addressable memory.
Building in C++ mode shows:
int write_inferior_memory (CORE_ADDR memaddr, const unsigned char *myaddr,
^
src/gdb/gdbserver/proc-service.c:93:64: error: invalid conversion from ‘int’ to ‘ps_err_e’ [-fpermissive]
return write_inferior_memory ((unsigned long) addr, buf, size);
^
It only works today by accident, write_inferior_memory does not return
a ps_err_e.
gdb/gdbserver/ChangeLog:
2015-08-27 Pedro Alves <palves@redhat.com>
* proc-service.c (ps_pdwrite): Return PS_ERR/PS_OK explicily.
Since we're using sighandler_t, nothing else refers to RETSIGTYPE in
gdb.
(Actually, given gdb/remote.c has been assuming signal handlers return
void for a long time, we could have gotten get rid of this even
without gnulib's sighandler_t.)
gdb/ChangeLog:
2015-08-27 Pedro Alves <palves@redhat.com>
* configure.ac: Remove AC_TYPE_SIGNAL call.
* configure, config.in: Regenerate.
This fixes 14 build errors like these in C++ mode:
src/gdb/extension.c: In function ‘void install_sigint_handler(const signal_handler*)’:
src/gdb/extension.c:698:41: error: invalid conversion from ‘void (*)()’ to ‘__sighandler_t {aka void (*)(int)}’ [-fpermissive]
signal (SIGINT, handler_state->handler);
^
In file included from build-gnulib/import/signal.h:52:0,
from ../../src/gdb/extension.c:24:
/usr/include/signal.h:102:23: error: initializing argument 2 of ‘void (* signal(int, __sighandler_t))(int)’ [-fpermissive]
extern __sighandler_t signal (int __sig, __sighandler_t __handler)
^
Instead of this everywhere:
- RETSIGTYPE (*handle_sigint_for_compare) () = handle_sigint;
+ RETSIGTYPE (*handle_sigint_for_compare) (int) = handle_sigint;
Use sighandler_t (a GNU extension). That's OK to use unconditionaly
because gnulib's signal.h replacement makes sure that it is available.
gdb/ChangeLog:
2015-08-27 Pedro Alves <palves@redhat.com>
* cp-support.c (gdb_demangle): Use sighandler_t. Remove cast.
* extension-priv.h: Include signal.h.
(struct signal_handler) <handler>: Change type to sighandler_t.
* extension.c (install_gdb_sigint_handler): Use sighandler_t.
* inflow.c (sigint_ours, sigquit_ours): Change type to
sighandler_t.
(child_terminal_inferior): Remove casts.
(child_terminal_ours_1, new_tty): Use sighandler_t. Remove casts.
(osig): Change type to sighandler_t.
* nto-procfs.c (ofunc): Change type to sighandler_t.
(procfs_wait): Remove casts.
* remote-m32r-sdi.c (m32r_wait, m32r_load): Use sighandler_t.
* remote-sim.c (gdbsim_wait): Use sighandler_t.
* utils.c (wait_to_die_with_timeout): Use sighandler_t.
This gives us a signal.h replacement that makes sure the sighandler_t
typedef (a GNU extension) is always available. A follow up patch will
make use of this.
gdb/ChangeLog:
2015-08-27 Pedro Alves <palves@redhat.com>
* gnulib/update-gnulib.sh (IMPORTED_GNULIB_MODULES): Add signal-h.
* gnulib/aclocal.m4: Renegerate.
* gnulib/config.in: Renegerate.
* gnulib/configure: Renegerate.
* gnulib/import/Makefile.am: Update.
* gnulib/import/Makefile.in: Regenerate.
* gnulib/import/m4/gnulib-cache.m4: Update.
* gnulib/import/m4/gnulib-comp.m4: Update.
* gnulib/import/m4/signal_h.m4: New file.
* gnulib/import/signal.in.h: New file.
The remote packet buffer size is currently capped to 16384 mostly for
historical reasons, related to use of alloca. Stop using alloca and
remove the limitation.
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-08-27 Pedro Alves <palves@redhat.com>
* remote.c (DEFAULT_MAX_MEMORY_PACKET_SIZE)
(MIN_MEMORY_PACKET_SIZE): New.
(MAX_REMOTE_PACKET_SIZE, MIN_REMOTE_PACKET_SIZE): Delete.
(get_memory_packet_size): Adjust. No longer limit the max packet
size.
(set_memory_packet_size): Adjust, and remove dead code.
(remote_check_symbols): Use xmalloc and a cleanup instead of
alloca.
(remote_packet_size): No longer cap the packet size.
(putpkt_binary): Use xmalloc and a cleanup instead of alloca.
This patch improves one of the compile error messages by mentioning the
language.
Before - No compiler support for this language.
After - No compiler support for language <language>.
gdb/ChangeLog:
2015-08-26 Luis Machado <lgustavo@codesourcery.com>
* compile/compile.c (compile_to_object): Mention language in
error message.
Due to the lack of debug information in the binary, GDB is unable to figure
out what language is being used. This may be a problem when doing remote
debugging and the binary stops at the entry point containing asm code.
In this case GDB will switch to asm as current language and will not switch
back to C when it reaches main, which in turn causes the compile feature check
to malfunction.
This is solved by forcing the language to C after reaching main.
gdb/testsuite/ChangeLog:
2015-08-26 Luis Machado <lgustavo@codesourcery.com>
* gdb.compile/compile-ifunc.exp (with_test_prefix): Force language
to C.
We currently set attach_flag when attaching to a process, so we should
make sure to unset it when forking a new process. Otherwise attach_flag
would remain set after forking, if the previous process associated with
the inferior was attached to.
gdb/ChangeLog:
* target.c (target_pre_inferior): Unset attach_flag.
gdb/testsuite/ChangeLog:
* gdb.base/run-after-attach.exp: New test file.
* gdb.base/run-after-attach.c: New test file.
I made a mistake while handling my previous patch. A change in
gdbarch causes a build failure.
gdb/ChangeLog:
* gdbarch.sh (append_name): Fix type in XRESIZEVEC.
* gdbarch.c: Re-generate.
This patch fixes a segmentation fault in native GDB when
handling an exec event with follow-exec-mode set to "new".
The stack trace from the segfault was this:
0 0x0000000000669594 in gdbarch_data (gdbarch=0x0, data=0x20da7a0)
at /scratch/dbreazea/sandbox/exec-nat/binutils-gdb/gdb/gdbarch.c:4847
1 0x00000000004d430e in get_remote_arch_state ()
at /scratch/dbreazea/sandbox/exec-nat/binutils-gdb/gdb/remote.c:603
2 0x00000000004d431e in get_remote_state ()
at /scratch/dbreazea/sandbox/exec-nat/binutils-gdb/gdb/remote.c:616
3 0x00000000004dda8b in discard_pending_stop_replies (inf=0x217c710)
at /scratch/dbreazea/sandbox/exec-nat/binutils-gdb/gdb/remote.c:5775
4 0x00000000006a5928 in observer_inferior_exit_notification_stub (
data=0x4dda7a <discard_pending_stop_replies>, args_data=0x7fff12c258f0)
at ./observer.inc:1137
5 0x00000000006a419a in generic_observer_notify (subject=0x21dfbe0,
args=0x7fff12c258f0)
at /scratch/dbreazea/sandbox/exec-nat/binutils-gdb/gdb/observer.c:167
6 0x00000000006a59ba in observer_notify_inferior_exit (inf=0x217c710)
at ./observer.inc:1162
7 0x00000000007981d5 in exit_inferior_1 (inftoex=0x217c710, silent=1)
at /scratch/dbreazea/sandbox/exec-nat/binutils-gdb/gdb/inferior.c:244
8 0x00000000007982f2 in exit_inferior_num_silent (num=1)
at /scratch/dbreazea/sandbox/exec-nat/binutils-gdb/gdb/inferior.c:286
9 0x000000000062f93d in follow_exec (ptid=...,
execd_pathname=0x7fff12c259a0 "/scratch/dbreazea/sandbox/exec-nat/build/gdb/testsuite/gdb.base/execd-prog")
at /scratch/dbreazea/sandbox/exec-nat/binutils-gdb/gdb/infrun.c:1195
In follow_exec we were creating a new inferior for the execd program,
as required by the exec mode, but we were doing it before calling
exit_inferior_num_silent on the original inferior. So on entry to
exit_inferior_num_silent we had two inferiors with the same ptid.
In the calls made by exit_inferior_num_silent, the current inferior
is temporarily saved and replaced in order to make use of functions
that only operate on the current inferior (for example, in
do_all_continuations, called while deleting the threads of the original
inferior). When we restored the original inferior, we just took the
first inferior that matched the ptid of the original and got the new
(wrong) one. It hadn't been initialized yet and had no gdbarch
pointer, and GDB segfaulted.
The fix for that is to call exit_inferior_num_silent before adding the new
inferior, so that we never have two inferiors with the same ptid. Then
exit_inferior_num_silent uses the original inferior as the current inferior
throughout, and can find a valid gdbarch pointer.
Once we have finished with the exit of the old inferior and added the
new one, we need to create a new thread for the new inferior. In the
function that called follow_exec, handle_inferior_event_1,
ecs->event_thread now points to the thread that was deleted with the
exit of the original inferior. To remedy this we create the new thread,
and once we return from follow_exec we reset ecs->event_thread.
Note that we are guaranteed that we can reset ecs->event_thread
safely using inferior_thread because we have set the current
inferior in follow_exec, and inferior_ptid was set by the call
to context_switch at the beginning of exec event handling.
gdb/ChangeLog:
* infrun.c (follow_exec): Re-order operations for
handling follow-exec-mode "new".
(handle_inferior_event_1): Assign ecs->event_thread
to the current thread.
* remote.c (get_remote_arch_state): Add an assertion.
This patch implements a new GDB test for follow-exec-mode. Although
there is a GDB test for debugging across an exec, there is no test for
follow-exec-mode. This test is derived from gdb.base/foll-exec.exp,
and re-uses execd-prog.c as the program to exec.
The following behavior is tested:
follow-exec-mode == "same"
- 'next' over the exec, check for one inferior
- 'continue' past the exec to a breakpoint, check for one inferior
- after the exec, use a 'run' command to run the current binary
follow-exec-mode == "new"
- 'next' over the exec, check for two inferiors
- 'continue' past the exec to a breakpoint, check for two inferiors
- after the exec, use a 'run' command to run the current binary
- after the exec, use the 'inferior' command to switch inferiors,
then use a 'run' command to run the current binary
Note that single-step breakpoints do not survive across an exec.
There has to be a breakpoint in the execed program in order for
it to stop right after the exec.
gdb/testsuite/ChangeLog:
* gdb.base/foll-exec-2.c: New test program.
* gdb.base/foll-exec-2.exp: New test.
Currently, when remote debugging, if you type Ctrl-C just while the
target stopped for an internal event, and GDB is busy doing something
that takes a while (e.g., fetching chunks of a shared library off of
the target, with vFile, to process ELF headers and debug info), the
Ctrl-C is lost.
The patch hooks up the QUIT macro to a new target method that lets the
target react to the double-Ctrl-C before the event loop is reached,
which allows reacting to a double-Ctrl-C even when GDB is busy doing
some long operation and not waiting for a stop reply. That end result
is:
(gdb) c
Continuing.
^C
^C
Interrupted while waiting for the program.
Give up waiting? (y or n) y
Quit
(gdb) info threads
Id Target Id Frame
* 1 Thread 11673 0x00007ffff7deb240 in _dl_debug_state () from target:/lib64/ld-linux-x86-64.so.2
(gdb)
If, however, GDB is waiting for a stop reply (because the target has
been resumed, with e.g., vCont;c), but the target isn't responding, we
now get:
(gdb) c
Continuing.
^C
^C
The target is not responding to interrupt requests.
Stop debugging it? (y or n) y
Disconnected from target.
(gdb) info threads
No threads.
This offers to disconnect, because when we're waiting for a stop
reply, there's nothing else we can send the target other than an
interrupt request. And if that doesn't work, there's nothing else we
can do.
The Ctrl-C is presently lost because until we get to a user-visible
stop, the SIGINT handler that is installed is the one that forwards
the interrupt to the remote side, with the \003 "packet" [1]. But,
gdbserver ignores an interrupt request if the program is stopped.
Still, even if it didn't, the server can only report back a
stop-because-of-SIGINT when the program is next resumed. And it may
take a while to actually re-resume the target.
[1] - In the old sync days, the remote target would react to a
double-Ctrl-C by asking users whether they wanted to give up waiting
and disconnect. The code is still there, but it it isn't reacheable
on most hosts, which support serial connections in async mode
(probably only DJGPP doesn't). Even then, in sync mode, remote.c's
SIGINT handler is only installed while the target is resumed, and is
removed as soon as the target sends back a stop reply. That means
that a Ctrl-C just while GDB is processing an internal event can end
up with an odd "Quit" at the prompt instead of "Program stopped by
SIGINT". In contrast, in async mode, remote.c's SIGINT handler is set
up as long as target_terminal_inferior or
target_terminal_ours_for_output are in effect (IOW, until we get a
user-visible stop and call target_terminal_ours), so the user
shouldn't get back a spurious Quit. However, it's still desirable to
be able to interrupt a long-running GDB operation, if GDB takes a
while to re-resume the target or get back to the event loop.
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-08-24 Pedro Alves <palves@redhat.com>
* defs.h (maybe_quit): Declare.
(QUIT): Now calls maybe_quit.
* event-loop.c (clear_async_signal_handler)
(async_signal_handler_is_marked): New functions.
* event-loop.h (async_signal_handler_is_marked)
(clear_async_signal_handler): New declarations.
* remote.c (remote_check_pending_interrupt): New function.
(interrupt_query): Use make_cleanup_restore_target_terminal. No
longer check whether the target is async. If waiting for a stop
reply, and a Ctrl-C as been sent to the target, offer to
disconnect, and throw TARGET_CLOSE_ERROR instead of a quit.
Otherwise do not disconnect and throw a quit.
(_initialize_remote): Install remote_check_pending_interrupt as
to_check_pending_interrupt.
* target.c (target_check_pending_interrupt): New function.
* target.h (struct target_ops) <to_check_pending_interrupt>: New
field.
(target_check_pending_interrupt): New declaration.
* utils.c (maybe_quit): New function.
* target-delegates.c: Regenerate.
In debug_reg_change_callback, we change debug registers of each LWP.
It makes more sense to print LWP's pid rather than group leader's pid.
gdb:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* nat/aarch64-linux-hw-point.c (debug_reg_change_callback):
Rename local variable pid to tid, and get lwpid of lwp. Update
debug output.
GDB's current behavior when dealing with non-local references in the
context of nested fuctions is approximative:
- code using valops.c:value_of_variable read the first available stack
frame that holds the corresponding variable (whereas there can be
multiple candidates for this);
- code directly relying on read_var_value will instead read non-local
variables in frames where they are not even defined.
This change adds the necessary context to symbol reads (to get the block
they belong to) and to blocks (the static link property, if any) so that
GDB can make the proper decisions when dealing with non-local varibale
references.
gdb/ChangeLog:
* ada-lang.c (ada_read_var_value): Add a var_block argument
and pass it to default_read_var_value.
* block.c (block_static_link): New accessor.
* block.h (block_static_link): Declare it.
* buildsym.c (finish_block_internal): Add a static_link
argument. If there is a static link, associate it to the new
block.
(finish_block): Add a static link argument and pass it to
finish_block_internal.
(end_symtab_get_static_block): Update calls to finish_block and
to finish_block_internal.
(end_symtab_with_blockvector): Update call to
finish_block_internal.
* buildsym.h: Forward-declare struct dynamic_prop.
(struct context_stack): Add a static_link field.
(finish_block): Add a static link argument.
* c-exp.y: Remove an obsolete comment (evaluation of variables
already start from the selected frame, and now they climb *up*
the call stack) and propagate the block information to the
produced expression.
* d-exp.y: Likewise.
* f-exp.y: Likewise.
* go-exp.y: Likewise.
* jv-exp.y: Likewise.
* m2-exp.y: Likewise.
* p-exp.y: Likewise.
* coffread.c (coff_symtab_read): Update calls to finish_block.
* dbxread.c (process_one_symbol): Likewise.
* xcoffread.c (read_xcoff_symtab): Likewise.
* compile/compile-c-symbols.c (convert_one_symbol): Promote the
"sym" parameter to struct block_symbol, update its uses and pass
its block to calls to read_var_value.
(convert_symbol_sym): Update the calls to convert_one_symbol.
* compile/compile-loc2c.c (do_compile_dwarf_expr_to_c): Update
call to read_var_value.
* dwarf2loc.c (block_op_get_frame_base): New.
(dwarf2_block_frame_base_locexpr_funcs): Implement the
get_frame_base method.
(dwarf2_block_frame_base_loclist_funcs): Likewise.
(dwarf2locexpr_baton_eval): Add a frame argument and use it
instead of the selected frame in order to evaluate the
expression.
(dwarf2_evaluate_property): Add a frame argument. Update call
to dwarf2_locexpr_baton_eval to provide a frame in available and
to handle the absence of address stack.
* dwarf2loc.h (dwarf2_evaluate_property): Add a frame argument.
* dwarf2read.c (attr_to_dynamic_prop): Add a forward
declaration.
(read_func_scope): Record any available static link description.
Update call to finish_block.
(read_lexical_block_scope): Update call to finish_block.
* findvar.c (follow_static_link): New.
(get_hosting_frame): New.
(default_read_var_value): Add a var_block argument. Use
get_hosting_frame to handle non-local references.
(read_var_value): Add a var_block argument and pass it to the
LA_READ_VAR_VALUE method.
* gdbtypes.c (resolve_dynamic_range): Update calls to
dwarf2_evaluate_property.
(resolve_dynamic_type_internal): Likewise.
* guile/scm-frame.c (gdbscm_frame_read_var): Update call to
read_var_value, passing it the block coming from symbol lookup.
* guile/scm-symbol.c (gdbscm_symbol_value): Update call to
read_var_value (TODO).
* infcmd.c (finish_command_continuation): Update call to
read_var_value, passing it the block coming from symbol lookup.
* infrun.c (insert_exception_resume_breakpoint): Likewise.
* language.h (struct language_defn): Add a var_block argument to
the LA_READ_VAR_VALUE method.
* objfiles.c (struct static_link_htab_entry): New.
(static_link_htab_entry_hash): New.
(static_link_htab_entry_eq): New.
(objfile_register_static_link): New.
(objfile_lookup_static_link): New.
(free_objfile): Free the STATIC_LINKS hashed map if needed.
* objfiles.h: Include hashtab.h.
(struct objfile): Add a static_links field.
(objfile_register_static_link): New.
(objfile_lookup_static_link): New.
* printcmd.c (print_variable_and_value): Update call to
read_var_value.
* python/py-finishbreakpoint.c (bpfinishpy_init): Likewise.
* python/py-frame.c (frapy_read_var): Update call to
read_var_value, passing it the block coming from symbol lookup.
* python/py-framefilter.c (extract_sym): Add a sym_block
parameter and set the pointed value to NULL (TODO).
(enumerate_args): Update call to extract_sym.
(enumerate_locals): Update calls to extract_sym and to
read_var_value.
* python/py-symbol.c (sympy_value): Update call to
read_var_value (TODO).
* stack.c (read_frame_local): Update call to read_var_value.
(read_frame_arg): Likewise.
(return_command): Likewise.
* symtab.h (struct symbol_block_ops): Add a get_frame_base
method.
(struct symbol): Add a block field.
(SYMBOL_BLOCK): New accessor.
* valops.c (value_of_variable): Remove frame/block handling and
pass the block argument to read_var_value, which does this job
now.
(value_struct_elt_for_reference): Update calls to
read_var_value.
(value_of_this): Pass the block found to read_var_value.
* value.h (read_var_value): Add a var_block argument.
(default_read_var_value): Likewise.
gdb/testsuite/ChangeLog:
* gdb.base/nested-subp1.exp: New file.
* gdb.base/nested-subp1.c: New file.
* gdb.base/nested-subp2.exp: New file.
* gdb.base/nested-subp2.c: New file.
* gdb.base/nested-subp3.exp: New file.
* gdb.base/nested-subp3.c: New file.
This patch moves aarch64_linux_new_thread in GDB and GDBserver to
nat/aarch64-linux.c.
gdb:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (aarch64_linux_new_thread): Move it to ...
* nat/aarch64-linux.c (aarch64_linux_new_thread): ... here.
* nat/aarch64-linux.h (aarch64_linux_new_thread): Declare.
gdb/gdbserver:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_linux_new_thread): Remove.
gdb:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (aarch64_linux_prepare_to_resume): Use
lwp_arch_private_info and ptid_of_lwp.
gdb/gdbserver:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_linux_prepare_to_resume): Use
lwp_arch_private_info and ptid_of_lwp.
This patch addes argument pid in aarch64_get_debug_reg_state, so that
its interface is the same on both GDB and GDBserver.
gdb/gdbserver:
2015-018-25 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_get_debug_reg_state): Add argument pid.
Find proc_info by find_process_pid. All callers updated.
This patch makes function debug_reg_change_callback in GDB and GDBserver
look the same, so that the following patch can move them to
nat/aarch64-linux-hw-point.c.
gdb:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (debug_reg_change_callback): Use
ptid_of_lwp to get ptid of lwp.
gdb/gdbserver:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (debug_reg_change_callback): Use
ptid_of_lwp to get ptid of lwp.
gdb:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (debug_reg_change_callback): Use
debug_printf.
gdb/gdbserver:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (debug_reg_change_callback): Use
debug_printf.
This patch is to use phex in debug_reg_change_callback to make it
identical in GDB and GDBserver.
gdb/gdbserver:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (debug_reg_change_callback): Use phex.
We print PID rather than LWPID in the debug output, so we need call
ptid_get_pid in debug_reg_change_callback.
gdb:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* aarch64-linux-nat.c (debug_reg_change_callback): Call
ptid_get_pid rather than ptid_get_lwp.
This patch makes more bits on aarch64 watchpoint between GDB and GDBserver
look similar.
gdb/gdbserver:
2015-08-25 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_dr_update_callback_param) <pid>:
Remove.
(debug_reg_change_callback): Remove argument entry and add argument
lwp. Remove local variable thread. Don't print thread id in the
debugging output. Don't check whether pid of thread equals to pid.
(aarch64_notify_debug_reg_change): Don't set param.pid. Call
iterate_over_lwps instead find_inferior.
Ref: https://sourceware.org/ml/gdb-patches/2015-08/msg00675.html
If multiprocess extensions are off (because specific gdbserver port
doesn't support them), then when gdbserver doesn't have a thread
selected yet, and GDB sends Hg packet to select one, gdbserver
crashes. That's because extracting the desired thread id out of the
packet that GDB sent depends on the current thread to fill in the
missing process id ... Fix this by getting the process id from the
first (and only) process in the processes list instead.
The GNU/Linux port doesn't trip on this because it always runs with
multiprocess extensions enabled. To make it easier to catch such
regressions going forward, this commit also adds a new smoke test that
spawns gdbserver, connects to it and runs to main with the
multiprocess extensions force-disabled.
gdb/gdbserver/ChangeLog:
2015-08-24 Pedro Alves <palves@redhat.com>
* inferiors.c (get_first_process): New function.
* inferiors.h (get_first_process): New declaration.
* remote-utils.c (read_ptid): Default to the first process in the
list, instead of to the current thread's process.
gdb/testsuite/ChangeLog:
2015-08-24 Pedro Alves <palves@redhat.com>
* gdb.server/connect-without-multi-process.c: New file.
* gdb.server/connect-without-multi-process.exp: New file.
Being able to force-disable the RSP multiprocess extensions is useful
for testing.
gdb/ChangeLog:
2015-08-24 Pedro Alves <palves@redhat.com>
* NEWS (New commands): Mention set/show remote
multiprocess-extensions-packet.
* remote.c (remote_query_supported): Only tell the server to use
the multiprocess extensions if the user hasn't force-disabled them
with "set remote multiprocess-extensions-packet off".
gdb/doc/ChangeLog:
2015-08-24 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Remote Configuration): Document the "set/show
remote multiprocess-extensions-packet" commands.
After the last gnulib import (Dec 2012), gnulib upstream started
replacing mingw's 'struct timeval' with a version with 64-bit time_t,
for POSIX compliance:
commit f8e84098084b3b53bc6943a5542af1f607ffd477
Author: Bruno Haible <bruno@clisp.org>
Date: Sat Jan 28 18:12:10 2012 +0100
sys_time: Override 'struct timeval' on some native Windows platforms.
See:
https://lists.gnu.org/archive/html/bug-gnulib/2012-01/msg00372.html
However, that results in conflicts with native Winsock2's 'select':
select()'s argument
http://sourceforge.net/p/mingw-w64/mailman/message/29610438/
... and libiberty's timeval-utils.h timeval_add/timeval_sub, at the
least.
We don't really need the POSIX compliance, so this patch prepares us
to simply not use gnulib's 'struct timeval' replacement once a more
recent gnulib is imported, thus preserving the current behavior, by
adding a sys/time.h wrapper header that undefs gnulib's replacements,
and including that everywhere instead.
The SIZE -> OSIZE change is necessary because newer gnulib's
sys/time.h also includes windows.h/winsock2.h, which defines a
conflicting SIZE symbol.
Cross build-tested mingw-w64 32-bit and 64-bit.
Regtested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-08-24 Pedro Alves <palves@redhat.com>
* Makefile.in (HFILES_NO_SRCDIR): Add common/gdb_sys_time.h.
* common/gdb_sys_time.h: New file.
* event-loop.c: Include gdb_sys_time.h instead of sys/time.h.
* gdb_select.h: Likewise.
* gdb_usleep.c: Likewise.
* maint.c: Likewise.
* mi/mi-main.c: Likewise.
* mi/mi-parse.h: Likewise.
* remote-fileio.c: Likewise.
* remote-m32r-sdi.c: Likewise.
* remote.c: Likewise.
* ser-base.c: Likewise.
* ser-pipe.c: Likewise.
* ser-tcp.c: Likewise.
* ser-unix.c: Likewise.
* symfile.c: Likewise.
* symfile.c: Likewise. Rename OSIZE to SIZE throughout.
* target-memory.c: Include gdb_sys_time.h instead of sys/time.h.
* utils.c: Likewise.
gdb/gdbserver/ChangeLog:
2015-08-24 Pedro Alves <palves@redhat.com>
* debug.c: Include gdb_sys_time.h instead of sys/time.h.
* event-loop.c: Likewise.
* remote-utils.c: Likewise.
* tracepoint.c: Likewise.
Ref: https://sourceware.org/ml/gdb-patches/2015-08/msg00675.html
gdbserver/spu-low.c: In function 'spu_request_interrupt':
gdbserver/spu-low.c:639: error: incompatible type for argument 1 of 'ptid_get_lwp'
gdb/gdbserver/ChangeLog:
2015-08-24 Pedro Alves <palves@redhat.com>
* spu-low.c (spu_request_interrupt): Use lwpid_of instead of
ptid_get_lwp.
This makes z an int for gdb/testsuite/gdb.opt/inline-markers.c.
gdb/testsuite/ChangeLog:
2015-08-24 Luis Machado <lgustavo@codesourcery.com>
* gdb.opt/inline-markers.c: Make z int.
This fixes a typo in gdb/testsuite/gdb.opt/inline-markers.c, making
z a volatile variable.
gdb/testsuite/ChangeLog:
2015-08-24 Luis Machado <lgustavo@codesourcery.com>
* gdb.opt/inline-markers.c: Make z volatile.
While doing some powerpc Linux tests on a ppc 476 board using GCC 5.2, i
noticed inline-bt.exp, inline-cmds.exp and inline-locals.exp failing.
FAIL: gdb.opt/inline-bt.exp: continue to bar (1)
FAIL: gdb.opt/inline-bt.exp: backtrace from bar (1)
FAIL: gdb.opt/inline-bt.exp: continue to bar (2)
FAIL: gdb.opt/inline-bt.exp: backtrace from bar (2)
FAIL: gdb.opt/inline-bt.exp: continue to bar (3)
FAIL: gdb.opt/inline-bt.exp: backtrace from bar (3)
FAIL: gdb.opt/inline-cmds.exp: continue to bar (1)
FAIL: gdb.opt/inline-cmds.exp: backtrace from bar (1)
FAIL: gdb.opt/inline-cmds.exp: continue to bar (2)
FAIL: gdb.opt/inline-cmds.exp: backtrace from bar (2)
FAIL: gdb.opt/inline-cmds.exp: continue to marker
FAIL: gdb.opt/inline-cmds.exp: backtrace from marker
FAIL: gdb.opt/inline-cmds.exp: step into finish marker
FAIL: gdb.opt/inline-locals.exp: continue to bar (1)
FAIL: gdb.opt/inline-locals.exp: continue to bar (2)
FAIL: gdb.opt/inline-locals.exp: backtrace from bar (2)
FAIL: gdb.opt/inline-locals.exp: continue to bar (3)
FAIL: gdb.opt/inline-locals.exp: backtrace from bar (3)
They failed because the breakpoint supposedly inserted at bar was actually
inserted at noinline.
(gdb) break inline-markers.c:20^M
Breakpoint 2 at 0x1000079c: file gdb/testsuite/gdb.opt/inline-markers.c, line 20.^M
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, noinline () at gdb/testsuite/gdb.opt/inline-markers.c:35^M
35 inlined_fn (); /* inlined */^M
As we can see, line 20 is really inside bar, not noinline:
18 void bar(void)
19 {
20 x += y; /* set breakpoint 1 here */
21 }
Further investigation shows that this is really due to GCC 5's new
ICF pass (-fipa-icf), now enabled by default at -O2, which folds bar
and marker into noinline, where the call to inlined_fn was inlined.
This breaks the testcase since it expects to stop at specific spots.
I thought about two possible fixes for this issue.
- Disable the ICF pass manually when building the binary (-fno-ipa-icf).
This has the advantage of not having to touch the testcase sources themselves,
but the disadvantage of having to add conditional blocks to test the GCC
version. If we ever change GCC's default, we will have to adjust the
conditional block again to match GCC's behavior.
- Modify the testcase sources to make the identical functions unique.
This solution doesn't touch the testcase itself, but changes the source
code slightly in order to make bar, marker and inlined_fn unique. This
causes GCC's ICF pass to ignore these functions and not fold them into
a common identical function.
I'm good with either of them, but i'm more inclined to go with the second
one.
The attached patch implements this by adding the new global variable z, set
to 0, that gets added in different ways to marker and inlined_fn. Since it
is 0, it doesn't affect any possible value checks that we may wish to do
in the future (we currently only check for values changed by bar).
Ok?
ps: I also noticed GDB doesn't do a great job at stating that the breakpoint
was actually inserted at a different source line than previously requested,
so this sounds like a bug that should be fixed, if it is not just wrong
DWARF information (did not investigate it further).
gdb/testsuite/ChangeLog:
2015-08-24 Luis Machado <lgustavo@codesourcery.com>
* gdb.opt/inline-bt.c: New volatile global z.
* gdb.opt/inline-cmds.c: Likewise.
* gdb.opt/inline-locals.c: Likewise.
* gdb.opt/inline-markers.c: New extern global z.
(marker): Use z.
(inline_fn): Likewise.
Support for target dbug/picobug/dink32/m32r/mon2000/ppcbug was just
removed, but support for ARM RDI, Sparclet, Sparclite, Z8000, target
r3900, target array, target sds, target op50n and target w89k had
already been removed many years ago. Drop it all in one go.
gdb/doc/ChangeLog:
2015-08-24 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Embedded Processors) <ARM>: Remove references to RDI.
<M32R>: Remove references to M32R/D.
<M68K>: Remove references to target dbug.
<MIPS Embedded>: Remove references to target r3900 and target
array.
<PowerPC Embedded>: Remove references to target dink32 and target
ppcbug, target sds
<PA, Sparclet, Sparclite, Z8000>: Delete nodes.
Ref: https://sourceware.org/ml/gdb/2015-07/msg00011.html
All of these targets use gdb/monitor.c, which has bit rotted
years ago (I'd guess around ~6), and nobody seems to
have noticed:
| target | source |
|----------------+----------------------|
| target dbug | gdb/dbug-rom.c |
| target picobug | gdb/microblaze-rom.c |
| target dink32 | gdb/dink32-rom.c |
| target m32r | gdb/m32r-rom.c |
| target mon2000 | gdb/m32r-rom.c |
| target ppcbug | gdb/ppcbug-rom.c |
This deletes them, along with finally removing monitor.c.
A manual update will be done separately.
gdb/ChangeLog:
2015-08-24 Pedro Alves <palves@redhat.com>
* NEWS: Mention removed support for the various ROM monitors.
* Makefile.in (ALL_TARGET_OBS): Remove dbug-rom.o, dink32-rom.o,
ppcbug-rom.o, m32r-rom.o, dsrec.o and monitor.o from gdb_target_obs.
* configure.tgt (h8300-*-*): Remove monitor.o and m32r-rom.o from
gdb_target_obs.
(m68*-*-*): Remove monitor.o dbug-rom.o and dsrec.o from
gdb_target_obs.
(microblaze*-linux-*): Remove microblaze-rom.o, monitor.o and
dsrec.o from gdb_target_obs.
(microblaze*-*-*): Remove microblaze-rom.o, monitor.o and dsrec.o
from gdb_target_obs.
(powerpc-*-lynx*178): Remove monitor.o and dsrec.o from
gdb_target_obs.
(powerpc*-*-*): Remove monitor.o, dsrec.o, ppcbug-rom.o and
dink32-rom.o from gdb_target_obs.
(sh*-*-linux*): Remove monitor.o and dsrec.o from gdb_target_obs.
(sh*): Remove monitor.o and dsrec.o from gdb_target_obs.
* dbug-rom.c, dink32-rom.c, dsrec.c, m32r-rom.c, microblaze-rom.c,
monitor.c, monitor.h, ppcbug-rom.c, srec.h: Delete files.
This avoids two more types of FAILs with the gnu_vector test case.
First, for POWER targets newer GCCs emit an ABI note when invoked with
"-mcpu=native". Then the test case fell back to non-native compile,
producing code for a non-vector ABI. But that is not supported by GDB.
Thus the compiler note is now suppressed with "-Wno-psabi".
Second, on s390 the test case produced FAILs after falling back to a
non-vector ABI when using "finish" or "return" in a vector-valued
function. This was due to a long-standing known bug (Bug 8549). This
case is now detected, and KFAILs are emitted instead.
gdb/testsuite/ChangeLog:
* gdb.base/gnu_vector.exp: Try compilation with "-mcpu=native
-Wno-psabi" if "-mcpu=native" fails. For the tests with "finish"
and "return" use KFAIL when GDB can not read/write the vector
return value.
In C++ mode:
src/gdb/gdbserver/ax.c: In function ‘eval_result_type gdb_eval_agent_expr(eval_agent_expr_context*, agent_expr*, ULONGEST*)’:
src/gdb/gdbserver/ax.c:1335:11: error: invalid conversion from ‘int’ to ‘eval_result_type’ [-fpermissive]
return 1;
^
"1" as an enum eval_result_type is expr_eval_empty_expression, but
clearly this wants to return expr_eval_unhandled_opcode.
gdb/gdbserver/ChangeLog:
2015-08-21 Pedro Alves <palves@redhat.com>
* ax.c (gdb_eval_agent_expr): Return expr_eval_unhandled_opcode
instead of literal 1.
Fixes:
../../src/gdb/dwarf2read.c:127:15: error: declaration of ‘asection* dwarf2_section_info::<anonymous union>::asection’ [-fpermissive]
asection *asection;
^
In file included from ../../src/gdb/common/common-types.h:35:0,
from ../../src/gdb/common/common-defs.h:44,
from ../../src/gdb/defs.h:28,
from ../../src/gdb/dwarf2read.c:31:
../bfd/bfd.h:1596:3: error: changes meaning of ‘asection’ from ‘typedef struct bfd_section asection’ [-fpermissive]
} asection;
^
gdb/ChangeLog:
2015-08-21 Tom Tromey <tromey@redhat.com>
* dwarf2read.c (struct dwarf2_section_info): Rename field
'asection' to 'section'.
(dwarf2_has_info, get_section_bfd_owner, get_section_bfd_section)
(dwarf2_locate_sections, dwarf2_locate_sections)
(locate_dwz_sections, locate_v1_virtual_dwo_sections)
(dwarf2_locate_dwo_sections, dwarf2_locate_dwo_sections)
(dwarf2_locate_v2_dwp_sections): Adjust.
This patch fixes the following bug in TUI:
(gdb) break foo
No symbol table is loaded. Use the "file" command.
Make breakpoint pending on future shared library load? (y or [n]) <ENTER>
By submitting an empty command line to a secondary prompt, the line
corresponding to the secondary prompt is undesirably cleared and
overwritten. Outside of a secondary prompt, clearing the prompt line
after submitting an empty command line is intended behavior which
complements GDB's repeat-command shorthand. But inside a secondary
prompt, this behavior is undesired since the shorthand is not applicable
in that case. We should retain the secondary-prompt line even when it's
given no input.
This patch makes sure that a prompt that was given an empty command line
is cleared and overwritten only if it's not a secondary prompt. To
acheive this, a new predicate is defined which informs us whether the
current input handler is a secondary prompt.
gdb/ChangeLog:
* top.h (gdb_in_secondary_prompt_p): Declare.
* top.c (gdb_secondary_prompt_depth): Define.
(gdb_in_secondary_prompt_p): Define.
(gdb_readline_wrapper_cleanup): Decrement
gdb_secondary_prompt_depth.
(gdb_readline_wrapper): Increment gdb_secondary_prompt_depth.
* tui/tui-io.c (tui_getc): Don't clear the prompt line if we
are in a secondary prompt.
This is necessary to make sure that start_line is updated after a
command has been entered. Usually, start_line gets updated anyway
because most commands output text, and outputting text is done through
the function tui_puts, which updates start_line. However if a command
does not output text, then tui_puts will not get called and start_line
will not get updated in time for the next prompt to be displayed.
One can observe this bug by executing the command "delete" within TUI.
After executing, the prompt line
(gdb) delete
gets overwritten by the next prompt. With this patch, the prompt line
gets preserved.
gdb/ChangeLog:
* tui/tui-io.c (tui_getc): Use tui_putc instead of waddch to
emit the newline.
Running that test in a loop, I found a gdbserver core dump with the
following back trace:
Core was generated by `../gdbserver/gdbserver --once --multi :2346'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000406ab6 in inferior_regcache_data (inferior=0x0) at src/gdb/gdbserver/inferiors.c:236
236 return inferior->regcache_data;
(gdb) up
#1 0x0000000000406d7f in get_thread_regcache (thread=0x0, fetch=1) at src/gdb/gdbserver/regcache.c:31
31 regcache = (struct regcache *) inferior_regcache_data (thread);
(gdb) bt
#0 0x0000000000406ab6 in inferior_regcache_data (inferior=0x0) at src/gdb/gdbserver/inferiors.c:236
#1 0x0000000000406d7f in get_thread_regcache (thread=0x0, fetch=1) at src/gdb/gdbserver/regcache.c:31
#2 0x0000000000409271 in prepare_resume_reply (buf=0x20dd593 "", ptid=..., status=0x20edce0) at src/gdb/gdbserver/remote-utils.c:1147
#3 0x000000000040ab0a in vstop_notif_reply (event=0x20edcc0, own_buf=0x20dd590 "T05") at src/gdb/gdbserver/server.c:183
#4 0x0000000000426b38 in notif_write_event (notif=0x66e6c0 <notif_stop>, own_buf=0x20dd590 "T05") at src/gdb/gdbserver/notif.c:69
#5 0x0000000000426c55 in handle_notif_ack (own_buf=0x20dd590 "T05", packet_len=8) at src/gdb/gdbserver/notif.c:113
#6 0x000000000041118f in handle_v_requests (own_buf=0x20dd590 "T05", packet_len=8, new_packet_len=0x7fff742c77b8)
at src/gdb/gdbserver/server.c:2862
#7 0x0000000000413850 in process_serial_event () at src/gdb/gdbserver/server.c:4148
#8 0x0000000000413945 in handle_serial_event (err=0, client_data=0x0) at src/gdb/gdbserver/server.c:4196
#9 0x000000000041a1ef in handle_file_event (event_file_desc=5) at src/gdb/gdbserver/event-loop.c:429
#10 0x00000000004199b6 in process_event () at src/gdb/gdbserver/event-loop.c:184
#11 0x000000000041a735 in start_event_loop () at src/gdb/gdbserver/event-loop.c:547
#12 0x00000000004123d2 in captured_main (argc=4, argv=0x7fff742c7ac8) at src/gdb/gdbserver/server.c:3562
#13 0x000000000041252e in main (argc=4, argv=0x7fff742c7ac8) at src/gdb/gdbserver/server.c:3631
Clearly this means that a thread pushed a stop reply in the event
queue, and then before GDB confused the event, the whole process died,
along with its thread. But the pending thread event was left
dangling. When GDB fetched that event, gdbserver looked up the
corresponding thread, but found NULL; not expecting this, gdbserver
crashes when it tries to read this thread's registers.
gdb/gdbserver/
2015-08-21 Pedro Alves <palves@redhat.com>
PR gdb/18749
* inferiors.c (remove_thread): Discard any pending stop reply for
this thread.
* server.c (remove_all_on_match_pid): Rename to ...
(remove_all_on_match_ptid): ... this. Work with a filter ptid
instead of a pid.
(discard_queued_stop_replies): Change parameter to a ptid. Now
extern.
(handle_v_kill, kill_inferior_callback)
(process_serial_event): Adjust.
(captured_main): Call initialize_notif before starting the
program, thus before threads are created.
* server.h (discard_queued_stop_replies): Declare.
In all-stop mode, if the current thread disappears while stopping all
threads, gdbserver calls set_desired_thread(0) ['0' means "I want the
continue thread"] which just picks the first thread in the list.
This looks like a dangerous thing to do. GDBserver continues
processing whatever it was doing, but to the wrong thread. If
debugging more than one process, we may even pick the wrong process.
Instead, GDBserver should detect the situation and bail out of
whatever is was doing.
The backends used to pay attention to the set 'cont_thread' (the Hc
thread, used in the old way to resume threads, before vCont), but all
such 'cont_thread' checks have been eliminated meanwhile. The
remaining implicit dependencies that I found on there being a selected
thread in the backends are in the Ctrl-C handling, which some backends
use as thread to send a signal to. Even that seems to me to be better
handled by always using the first thread in the list or by using the
signal_pid PID.
In order to make this a systematic approach, I'm making
set_desired_thread never fallback to a random thread, and instead end
up with current_thread == NULL, like already done in non-stop mode.
Then I updated all callers to handle the situation.
I stumbled on this while fixing other bugs exposed by
gdb.threads/fork-plus-threads.exp test. The problems I saw were fixed
in a different way, but in any case, I think the potential for
problems is more or less obvious, and the resulting code looks a bit
less magical to me.
Tested on x86-64 Fedora 20, w/ native-extended-gdbserver board.
gdb/gdbserver/ChangeLog:
2015-08-21 Pedro Alves <palves@redhat.com>
* linux-low.c (wait_for_sigstop): Always switch to no thread
selected if the previously current thread dies.
* lynx-low.c (lynx_request_interrupt): Use the first thread's
process instead of the current thread's.
* remote-utils.c (input_interrupt): Don't check if there's no
current thread.
* server.c (gdb_read_memory, gdb_write_memory): If setting the
current thread to the general thread fails, error out.
(handle_qxfer_auxv, handle_qxfer_libraries)
(handle_qxfer_libraries_svr4, handle_qxfer_siginfo)
(handle_qxfer_spu, handle_qxfer_statictrace, handle_qxfer_fdpic)
(handle_query): Check if there's a thread selected instead of
checking whether there's any thread in the thread list.
(handle_qxfer_threads, handle_qxfer_btrace)
(handle_qxfer_btrace_conf): Don't error out early if there's no
thread in the thread list.
(handle_v_cont, myresume): Don't set the current thread to the
continue thread.
(process_serial_event) <Hg handling>: Also set thread_id if the
previous general thread is still alive.
(process_serial_event) <g/G handling>: If setting the current
thread to the general thread fails, error out.
* spu-low.c (spu_resume, spu_request_interrupt): Use the first
thread's lwp instead of the current thread's.
* target.c (set_desired_thread): If the desired thread was not
found, leave the current thread pointing to NULL. Return an int
(boolean) indicating success.
* target.h (set_desired_thread): Change return type to int.
GDB provides no indicator of progress during file operations, and can
appear to have locked up during slow remote transfers. This commit
updates GDB to print a warning each time a file is accessed over RSP.
An additional message detailing how to avoid remote transfers is
printed for the first transfer only.
gdb/ChangeLog:
* target.h (struct target_ops) <to_fileio_open>: New argument
warn_if_slow. Update comment. All implementations updated.
(target_fileio_open_warn_if_slow): New declaration.
* target.c (target_fileio_open): Renamed as...
(target_fileio_open_1): ...this. New argument warn_if_slow.
Pass warn_if_slow to implementation. Update debug printing.
(target_fileio_open): New function.
(target_fileio_open_warn_if_slow): Likewise.
* gdb_bfd.c (gdb_bfd_iovec_fileio_open): Use new function
target_fileio_open_warn_if_slow.
gdb/testsuite/ChangeLog:
* gdb.trace/pending.exp: Cope with remote transfer warnings.
This commit fixes a stale cleanup left by linux_mntns_access_fs.
gdb/ChangeLog:
* nat/linux-namespaces.c (linux_mntns_access_fs):
Do not overwrite old_chain.
These changes allow debugging multithreaded NPTL xtensa applications.
2015-08-20 Max Filippov <jcmvbkbc@gmail.com>
gdb/gdbserver/
* configure.srv (xtensa*-*-linux*): Add srv_linux_thread_db=yes.
* linux-xtensa-low.c (arch/xtensa.h gdb_proc_service.h): New
#includes.
(ps_get_thread_area): New function.
2015-08-20 Max Filippov <jcmvbkbc@gmail.com>
gdb/
* arch/xtensa.h: New file.
* xtensa-linux-nat.c (gdb_proc_service.h): New #include.
(ps_get_thread_area): New function.
* xtensa-linux-tdep.c (xtensa_linux_init_abi): Add call to
set_gdbarch_fetch_tls_load_module_address to enable TLS support.
* xtensa-tdep.c (osabi.h): New #include.
(xtensa_gdbarch_init): Call gdbarch_init_osabi to register
xtensa-specific hooks.
* xtensa-tdep.h (struct xtensa_elf_gregset_t): Add threadptr
member and move the structure to arch/xtensa.h.
This patch almost halves the time it takes to "target remote + run to
main" on a higher-latency connection.
E.g., I've got a ping time of ~85ms to an x86-64 machine on the gcc
compile farm (almost 2000km away from me), and I'm behind a ~16Mbit
ADSL. When I connect to a gdbserver debugging itself on that machine
and run to main, it takes almost 55 seconds:
[palves@gcc76] $ ./gdbserver :9999 ./gdbserver
[palves@home] $ ssh -L 9999:localhost:9999 gcc76.fsffrance.org
[palves@home] $ time ./gdb -data-directory=data-directory -ex "tar rem :9999" -ex "b main" -ex "c" -ex "set confirm off" -ex "quit"
Pristine gdb 7.10.50.20150820-cvs gets us:
...
Remote debugging using :9999
Reading symbols from target:/home/palves/gdb/build/gdb/gdbserver/gdbserver...done.
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
0x00007ffff7ddd190 in ?? () from target:/lib64/ld-linux-x86-64.so.2
Breakpoint 1 at 0x41200c: file ../../../src/gdb/gdbserver/server.c, line 3635.
Continuing.
Breakpoint 1, main (argc=1, argv=0x7fffffffe3d8) at ../../../src/gdb/gdbserver/server.c:3635
3635 ../../../src/gdb/gdbserver/server.c: No such file or directory.
/home/palves/gdb/build/gdb/gdbserver/gdbserver: No such file or directory.
real 0m54.803s
user 0m0.329s
sys 0m0.064s
While with the readahead cache added by this patch, it drops to:
real 0m29.462s
user 0m0.454s
sys 0m0.054s
I added a few counters to show cache hit/miss, and got:
readahead cache miss 142
readahead cache hit 310
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-08-21 Pedro Alves <palves@redhat.com>
* remote.c (struct readahead_cache): New.
(struct remote_state) <readahead_cache>: New field.
(remote_open_1): Invalidate the cache.
(readahead_cache_invalidate, readahead_cache_invalidate_fd): New
functions.
(remote_hostio_pwrite): Invalidate the readahead cache.
(remote_hostio_pread): Rename to ...
(remote_hostio_pread_vFile): ... this.
(remote_hostio_pread_from_cache): New function.
(remote_hostio_pread): Reimplement.
(remote_hostio_close): Invalidate the readahead cache.
Fixes implicit function declaration
error in gdb/procfs.c:4927 about undeclared
make_cleanup_close().
gdb/ChangeLog:
PR build/18843
* procfs.c: Include "filestuff.h".
These fields are currently used to track the location of the cursor
inside the command window. But their usefulness is questionable because
ncurses already internally keeps track of the location of the cursor,
whose coordinates we can query using the functions getyx(), getcurx() or
getcury(). It is an unnecessary pain to keep these fields in sync with
ncurses, and their meaning is not well-defined anyway. For instance, it
is not clear whether the coordinates held in these fields are
authoritative, or whether the coordinates reported by ncurses are.
So to keep things simple, this patch removes these fields and replaces
existing reads of these fields with calls to the appropriate ncurses
querying functions, and replaces writes to these fields with calls to
wmove() (when necessary and applicable).
In the function tui_cont_sig(), I removed the call to wmove() entirely
because moving to (start_line, curch) makes no sense. The move should
have been to (cur_line, curch) -- which would now be a no-op.
Tested on x86_64 Fedora 22, no obvious regressions.
gdb/ChangeLog:
* tui/tui-data.h (tui_command_info): Remove fields cur_line and
curch.
* tui/tui-data.c (tui_clear_win_detail) [CMD_WIN]: Don't set
cur_line or curch, instead call wmove().
(init_win_info) [CMD_WIN]: Likewise.
* tui/tui-io.c (tui_puts): Likewise. Don't read cur_line,
instead call getcury().
(tui_redisplay_readline): Don't set cur_line or curch.
(tui_mld_erase_entire_line): Don't read cur_line, instead call
getcury().
(tui_cont_sig): Remove call to wmove.
(tui_getc): Don't read cur_line or curch, instead call getcury()
or getyx(). Don't set curch.
* tui/tui-win.c (make_visible_with_new_height) [CMD_WIN]: Don't
set cur_line or curch. Always move cursor to (0,0).
Commit 221e1a37 (remote non-stop: Process initially stopped threads
before other commands) caused a test regression when testing with the
native-extended-gdbserver board:
FAIL: gdb.server/solib-list.exp: non-stop 1: non-stop interior stop (timeout)
This "interior stop" now happens before "target remote" prints the
prompt, so we should no longer explicitly expect it.
gdb/testsuite/ChangeLog:
2015-08-20 Pedro Alves <palves@redhat.com>
* gdb.server/solib-list.exp: No longer expect an interior stop in
non-stop mode.
The main motivation for this is making non-stop / all-stop behave
similarly on initial connection, in order to move in the direction of
reimplementing all-stop mode with the remote target always running in
non-stop mode.
When we connect to a remote target in non-stop mode, we may find
threads either running or already stopped. The act of connecting
itself does not force threads to stop. To handle that, the remote
non-stop connection is currently roughly like this:
#1 - Fetch list of remote threads (qXfer:threads:read, qfThreadInfo,
etc). All threads are assumed to be running until the target
reports an asynchronous stop reply for them.
#2 - Fetch the initial set of threads that were already stopped, with
the '?' packet. (In non-stop, this is coupled with the vStopped
mechanism to be able to retrieve the status of more than one
thread.)
The stop replies fetched in #2 are placed in the pending stop reply
queue, and left for the regular event loop to process. That is,
"target remote" finishes and returns _before_ those stops are
processed.
That means that it's possible to have GDB process further commands
before the initial set of stopped threads is reported to the user.
E.g., before the patch, note how the prompt is printed before the
frame:
Remote debugging using :9999
(gdb)
[Thread 15296] #1 stopped.
0x0000003615a011f0 in ?? ()
Even though thread #1 was not running, for a moment, the user can see
it as such:
$ gdb a.out -ex "set non-stop 1" -ex "tar rem :9999" -ex "info threads" -ex "info registers"
Remote debugging using :9999
Id Target Id Frame
* 1 Thread 4772 (running)
Target is executing. <<<<<<< info registers
(gdb)
[Thread 4772] #1 stopped.
0x0000003615a011f0 in ?? ()
To fix that, this commit makes gdb process all threads found already
stopped at connection time, before giving the prompt to the user.
The fix takes a cue from fork-child.c:startup_inferior [1], and
processes the events locally in remote.c, avoiding the whole
wait_for_inferior/handle_inferior_event path. I decided to try this
approach after noticing that:
- several cases in handle_inferior_event miss checking stop_soon.
- we don't want to fetch the thread list in normal_stop.
and trying to fix them was resulting in sprinkling stop_soon checks in
many places, and uglifying normal_stop even more.
While with this patch, I'm avoiding changing GDB's output other than
when the prompt is printed, I think this approach is more flexible if
we do want to change it. And also, it's likely easier to get rid of
the MI *running event that is still sent for threads that are
initially found stopped, if we want to.
This happens to fix the testsuite too. All non-stop tests are racy
against "target remote" / gdbserver testing currently. That is,
sometimes the tests run, but other times they're just skipped without
any indication of PASS/FAIL. When that happens, the logs show:
target remote localhost:2346
Remote debugging using localhost:2346
(gdb)
[Thread 25418] #1 stopped.
0x0000003615a011f0 in ?? ()
^CQuit
(gdb) Remote debugging from host 127.0.0.1
Killing process(es): 25418
monitor exit
(gdb) Remote connection closed
(gdb) testcase /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.threads/multi-create-ns-info-thr.exp completed in 61 seconds
The trouble here is that there's output after the prompt, and the
regex in question doesn't expect that:
-re "Remote debugging using .*$serialport_re.*$gdb_prompt $" {
verbose "Set target to $targetname"
return 0
}
[1] - before startup_inferior was added, we'd go through
wait_for_inferior/handle_inferior_event while going through the shell,
and that turned out problematic.
Tested on x86_64 Fedora 20, gdbserver.
gdb/ChangeLog:
2015-08-20 Pedro Alves <palves@redhat.com>
* infrun.c (print_target_wait_results): Make extern.
* infrun.h (print_target_wait_results): Declare.
* remote.c (set_stop_requested_callback): Delete.
(process_initial_stop_replies): New function.
(remote_start_remote): Use it.
(stop_reply_queue_length): New function.
gdb/testsuite/ChangeLog:
2015-08-20 Pedro Alves <palves@redhat.com>
* gdb.server/connect-stopped-target.c: New file.
* gdb.server/connect-stopped-target.exp: New file.
Here, in dwarfread.c:process_full_comp_unit:
/* Set symtab language to language from DW_AT_language. If the
compilation is from a C file generated by language preprocessors, do
not set the language if it was already deduced by start_subfile. */
if (!(cu->language == language_c
&& COMPUNIT_FILETABS (cust)->language != language_c))
COMPUNIT_FILETABS (cust)->language = cu->language;
in case start_subfile doesn't manage to deduce a language
COMPUNIT_FILETABS(cust)->language ends up as language_unknown, not
language_c. So the condition above evals false and we never set the
language from the cu's language.
gdb/ChangeLog:
2015-08-20 Pedro Alves <palves@redhat.com>
* dwarf2read.c (process_full_comp_unit): To tell whether
start_subfile managed to deduce a language, test for
language_unknown instead of language_c.
gdb/testsuite/ChangeLog:
2015-08-20 Pedro Alves <palves@redhat.com>
* gdb.dwarf2/comp-unit-lang.exp: New file.
* gdb.dwarf2/comp-unit-lang.c: New file.
Before this change, trying to evaluate the following Ada expression
yielded a syntax error, even though it's completely legal:
(gdb) p s'first = 'a'
Error in expression, near `'.
The problem lies in the lexer (gdb/ada-lex.l): at the point we reach "'a'",
we're still in the BEFORE_QUAL_QUOTE start condition (the mechanism to
distinguish character literals from other "tick" usages: qualified
expressions and attributes), so we consider that this quote is actually a
separate "tick".
This changes resets the start condition to INITIAL in the
{TICK}[a-zA-Z][a-zA-Z]+ rule (for attributes): attributes activate this
BEFORE_QUAL_QUOTE condition and in this case the above rule is always
executed rather than the <BEFORE_QUAL_QUOTE>"'" one (in flex, it's
always the longest match that is chosen). We now have instead:
(gdb) p s'first = 'a'
$1 = true
gdb/ChangeLog:
* ada-lex.l: Reset the start condition to INITIAL in the rule
that matches attributes.
gdb/testsuite/ChangeLog:
* gdb.ada/attr_ref_and_charlit.exp: New testcase.
* gdb.ada/attr_ref_and_charlit/foo.adb: New file.
Tested on x86_64-linux, no regression.
This change introduces a new function, dwarf2_string_attr(), which is
a wrapper for dwarf2_attr(). dwarf2read.c has been updated to
call dwarf2_string_attr in most instances where a string-valued
attribute is decoded to produce a string value. In most cases, it
simplifies the code; in some instances, the complexity of the code
remains unchanged.
I performed this change by looking for instances where the
result of DW_STRING was used in an assignment. Many of these
had a pattern which (roughly) looks something like this:
struct attribute *attr = NULL;
attr = dwarf2_attr (die, name, cu);
if (attr != NULL && DW_STRING (attr))
{
const char *str;
...
str = DW_STRING (attr);
... /* Use str in some fashion. */
}
Code of this form is transformed to look like this instead:
const char *str;
str = dwarf2_string_attr (die, name, cu)
if (str != NULL)
{
...
/* Use str in some fashion. */
...
}
In addition to invoking dwarf2_attr() and DW_STRING(),
dwarf2_string_attr() checks to make sure that the attribute's
`form' field matches one of DW_FORM_strp, DW_FORM_string, or
DW_FORM_GNU_strp_alt. If it does not match one of these forms,
it will return a NULL value in addition to calling complaint().
An earlier version of this patch did this type checking for one
particular instance where a string attribute was being decoded.
The situation that I was attempting to handle in that earlier patch is
this:
The Texas Instruments compiler uses the encoding for
DW_AT_MIPS_linkage_name for other purposes. TI uses the encoding,
0x2007, for TI_AT_TI_end_line which, unlike DW_AT_MIPS_linkage_name,
does not have a string-typed value. In this instance, GDB was attempting
to use an integer value as a string pointer, with predictable results.
(GDB would die with a segmentation fault.)
I've added a test which reproduces the problem that I was orignally
wanting to fix. It uses DW_AT_MIPS_linkage name with an associate
value which is a string, and again, where the value is a small
integer.
My test case causes GDB to segfault in an unpatched GDB. There
will be two PASSes in a patched GDB.
Unpatched GDB:
(gdb) ptype f
ERROR: Process no longer exists
UNRESOLVED: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype f
ERROR: Couldn't send ptype g to GDB.
UNRESOLVED: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype g
Patched GDB:
(gdb) ptype f
type = bool ()
(gdb) PASS: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype f
ptype g
type = bool ()
(gdb) PASS: gdb.dwarf2/dw2-bad-mips-linkage-name.exp: ptype g
I see no regressions on an x86_64 native target.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_string_attr): New function.
(lookup_dwo_unit, process_psymtab_comp_unit_reader)
(dwarf2_compute_name, dwarf2_physname, find_file_and_directory)
(read_call_site_scope, namespace_name, guess_full_die_structure_name)
(anonymous_struct_prefix, prepare_one_comp_unit): Use
dwarf2_string_attr in place of dwarf2_attr and DW_STRING.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-bad-mips-linkage-name.c: New file.
* gdb.dwarf2/dw2-bad-mips-linkage-name.exp: New file.
While handling "vFile:pread:" packets, gdbserver would read the
number of bytes requested regardless of whether this would fit
into the reply packet. gdbserver would then return a packet's
worth of data and discard the remainder. When accessing large
binaries GDB (via BFD) routinely makes large "vFile:pread:"
requests, resulting in gdbserver allocating large unnecessary
buffers and reading some portions of the file many times over.
This commit causes gdbserver to limit the number of bytes to be
read to a sensible maximum prior to allocating buffers and reading
data.
gdb/gdbserver/ChangeLog:
* hostio.c (handle_pread): Do not attempt to read more data
than hostio_reply_with_data can fit in a packet.
On some older versions of GNU/Linux, gdbserver now fails to build
due to an undefined reference to NT_ARM_VFP. Same issue on Android,
where this macros is undefined until Android API level 21 (Android
5.0 "Lollipop").
This patch modifies linux-aarch32-low.c to define that macros when
not already defined.
gdb/gdbserver/ChangeLog:
* linux-aarch32-low.c (NT_ARM_VFP): Define if not already defined.