aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-09-18btrace: non-stopMarkus Metzger6-3/+302
Support non-stop mode in record btrace. gdb/ * record-btrace.c (record_btrace_open): Remove non_stop check. * NEWS: Announce that record btrace supports non-stop mode. testsuite/ * gdb.btrace/non-stop.c: New. * gdb.btrace/non-stop.exp: New.
2015-09-18infrun: switch to NO_HISTORY threadMarkus Metzger2-1/+12
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.
2015-09-18btrace: asyncMarkus Metzger2-0/+32
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.
2015-09-18btrace: temporarily set inferior_ptid in record_btrace_start_replayingMarkus Metzger2-19/+56
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.
2015-09-18btrace: resume all requested threadsMarkus Metzger2-37/+43
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.
2015-09-18btrace: lock-stepMarkus Metzger2-77/+190
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.
2015-09-18btrace: add missing NO_HISTORYMarkus Metzger2-1/+9
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.
2015-09-18btrace: move breakpoint checking into stepping functionsMarkus Metzger2-6/+23
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.
2015-09-18btrace: split record_btrace_step_threadMarkus Metzger2-82/+113
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.
2015-09-18btrace: extract the breakpoint check from record_btrace_step_threadMarkus Metzger2-12/+35
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.
2015-09-18btrace: improve stepping debuggingMarkus Metzger2-4/+62
gdb/ * record-btrace.c (btrace_thread_flag_to_str) (record_btrace_cancel_resume): New. (record_btrace_step_thread): Call btrace_thread_flag_to_str. (record_btrace_resume): Print execution direction. (record_btrace_resume_thread): Call btrace_thread_flag_to_str. (record_btrace_wait): Call record_btrace_cancel_resume.
2015-09-18btrace: support to_stopMarkus Metzger3-9/+70
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.
2015-09-18btrace: fix non-stop check in to_waitMarkus Metzger2-1/+6
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 ().
2015-09-18Add missing PowerPC64 ld --save-restore-funcs docAlan Modra2-0/+14
* ld.texinfo: Document --{no-,}save-restore-funcs.
2015-09-18Add PowerPC64 ld --tls-get-addr-optimize.Alan Modra6-13/+54
Sometimes it may be of benefit to force use of the __tls_get_addr_opt call stub even when the glibc being used during linking does not advertise __tls_get_addr_opt. bfd/ * elf64-ppc.h (struct ppc64_elf_params <tls_get_addr_opt>): Rename from no_tls_get_addr_opt. * elf64-ppc.c: Update for rename and inversion of tls_get_addr_opt. (ppc64_elf_tls_setup): Set tls_get_addr_opt to 0 only when at default of -1. ld/ * emultempl/ppc64elf.em (params): Init tls_get_addr_opt field to -1. (OPTION_TLS_GET_ADDR_OPT): Define. (PARSE_AND_LIST_LONGOPTS): Handle --tls-get-addr-opt. (PARSE_AND_LIST_OPTIONS, PARSE_AND_LIST_ARGS_CASES): Likewise. * ld.texinfo: Document --tls-get-addr-optimize and --no-tls-get-addr-optimize.
2015-09-18Delay converting linker script defined symbols from absoluteAlan Modra13-8/+142
Giving linker script symbols defined outside of output sections a section-relative value early, leads to them being used in expressions as if they were defined inside an output section. This can mean loss of the section VMA, and wrong results. ld/ PR ld/18963 * ldexp.h (struct ldexp_control): Add rel_from_abs. (ldexp_finalize_syms): Declare. * ldexp.c (new_rel_from_abs): Keep absolute for expressions outside of output section statements. Set rel_from_abs. (make_abs, exp_fold_tree, exp_fold_tree_no_dot): Clear rel_from_abs. (struct definedness_hash_entry): Add final_sec, and comment. (update_definedness): Set final_sec. (set_sym_sections, ldexp_finalize_syms): New functions. * ldlang.c (lang_process): Call ldexp_finalize_syms. ld/testsuite PR ld/18963 * ld-scripts/pr18963.d, * ld-scripts/pr18963.t: New test. * ld-scripts/expr.exp: Run it. * ld-elf/provide-hidden-2.ld: Explicitly make "dot" absolute. * ld-mips-elf/gp-hidden.sd: Don't care about _gp section. * ld-mips-elf/no-shared-1-n32.d: Don't care about symbol shown at start of .data section. * ld-mips-elf/no-shared-1-n64.d: Likewise. * ld-mips-elf/no-shared-1-o32.d: Likewise.
2015-09-18Remove one unnecessary iteration in insertion sortAlan Modra2-4/+8
PR 18867 * elflink.c (elf_link_adjust_relocs): Correct start of insertion sort main loop.
2015-09-18Automatic date update in version.inGDB Administrator1-1/+1
2015-09-17Add test case for tracepoints with conditionsPierre Langlois3-0/+240
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.
2015-09-17Automatic date update in version.inGDB Administrator1-1/+1
2015-09-16Fix argument to compiled_cond, and add cases for compiled-condition.Wei-cheng Wang4-2/+79
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.
2015-09-16non-stop-fair-events.exp slower on software single-step && !displ-step targetsPedro Alves4-38/+96
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.
2015-09-16Make it easier to debug non-stop-fair-events.expPedro Alves2-3/+61
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.
2015-09-16Don't skip gdb.asm/asm-source.exp on aarch64Yao Qi3-0/+43
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.
2015-09-16Fix slowdown in ld -r for most common case of out-of-order relocsAlan Modra2-15/+58
I chose insertion sort since relocs are mostly sorted, but there is a common case we can handle better; A run of relocs put out of order due to not linking input files in order. PR 18867 * elflink.c (elf_link_adjust_relocs): Modify insertion sort to insert a run. Return status in case of malloc failure. Adjust callers.
2015-09-16Automatic date update in version.inGDB Administrator1-1/+1
2015-09-15[Ada] Enhance type printing for arrays with variable-sized elementsPierre-Marie de Rodat7-3/+140
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.
2015-09-15Handle clang naming of function static local variable.Doug Evans2-1/+6
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.
2015-09-15xtensa: generate PLT entries for call0 ABIMax Filippov2-7/+20
2015-09-15 Max Filippov <jcmvbkbc@gmail.com> bfd/ * elf32-xtensa.c (elf_xtensa_be_plt_entry) (elf_xtensa_le_plt_entry): Emit 'entry' instruction only for windowed ABI. (elf_xtensa_create_plt_entry): Generate 'l32r' offsets and fix up instructions according to ABI.
2015-09-15Fix PR/18564 - regression in showing __thread so extern variablePhilippe Waroquiers8-13/+185
Ensure tls variable address is not relocated, as the msym addr is an offset in the thread local storage of the shared library/object.
2015-09-15gdb/doc: revert previous vforkdone changePedro Alves2-6/+11
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.
2015-09-15[AArch64] Use debug_printf instead of fprintf_unfilteredPierre Langlois2-129/+160
GDBserver uses debug_printf to print debugging output. This patch makes GDB use this too so we can share some of this code with GDBserver later. gdb/ChangeLog: * aarch64-tdep.c (decode_add_sub_imm): Use debug_printf. (decode_adrp): Likewise. (decode_b): Likewise. (decode_bcond): Likewise. (decode_br): Likewise. (decode_cb): Likewise. (decode_eret): Likewise. (decode_movz): Likewise. (decode_orr_shifted_register_x): Likewise. (decode_ret): Likewise. (decode_stp_offset): Likewise. (decode_stp_offset_wb): Likewise. (decode_stur): Likewise. (decode_tb): Likewise. (aarch64_analyze_prologue): Likewise. (pass_in_x): Likewise. (pass_in_v): Likewise. (pass_on_stack): Likewise. (aarch64_push_dummy_call): Likewise. (aarch64_extract_return_value): Likewise. (aarch64_store_return_value): Likewise. (aarch64_return_value): Likewise. (aarch64_record_asimd_load_store): Likewise. (aarch64_record_load_store): Likewise. (aarch64_record_data_proc_simd_fp): Likewise.
2015-09-15[ppc64le] Use skip_entrypoint for skip_trampoline_codeJan Kratochvil8-2/+177
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.
2015-09-15gdbserver: Fix exec stop reply reporting conditionsPedro Alves2-1/+7
gdb/gdbserver/ChangeLog: 2015-09-15 Pedro Alves <palves@redhat.com> * remote-utils.c (prepare_resume_reply) <TARGET_WAITKIND_EXECD>: Check whether to report exec events instead of checking whether multiprocess is enabled.
2015-09-15Move ChangeLog entry to proper placePedro Alves2-7/+7
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.
2015-09-15PR remote/18965: vforkdone stop reply should indicate parent PIDPedro Alves4-15/+26
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.
2015-09-15Fix typoYao Qi2-1/+6
gdb/gdbserver: 2015-09-15 Yao Qi <yao.qi@linaro.org> * server.c (handle_query): Check string comparison using "else if" instead of "if".
2015-09-15Fix gdb.threads/non-ldr-exc-3.exp racePedro Alves2-5/+6
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.
2015-09-15Support single step by arch or targetYao Qi10-10/+170
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.
2015-09-15[gdbserver] Rename supports_conditional_breakpoints to ↵Yao Qi9-30/+51
supports_hardware_single_step 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.
2015-09-15aarch64 multi-arch support (part 2): siginfo fixupYao Qi6-1/+291
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.
2015-09-15Automatic date update in version.inGDB Administrator1-1/+1
2015-09-15Fix the SH behavior for EF_SH_PIC flag in FDPIC ABIRich Felker2-2/+8
Fix it so that it's compatible with the kernel and other FDPIC targets. * elf32-sh.c (sh_elf_relocate_section): Set EF_SH_PIC flag instead of clearing it on cross-section relocations. (sh_elf_merge_private_data): Clear EF_SH_PIC flag by default.
2015-09-14Bail out of processing stop if hook-stop resumes target / changes contextPedro Alves9-156/+341
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.
2015-09-14[Ada] Fix the evaluation of access to packed array subscriptPierre-Marie de Rodat7-2/+133
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.
2015-09-14Remove duplicate gdb/NEWS entryPedro Alves2-6/+5
Commit fbea99ea8a06 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.
2015-09-14btrace, test: remove buffer-size test with unlimited buffer sizeMarkus Metzger2-11/+6
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.
2015-09-14Automatic date update in version.inGDB Administrator1-1/+1
2015-09-13Automatic date update in version.inGDB Administrator1-1/+1
2015-09-12Set .plt entry size to 0 in elf32-hppa.cJohn David Anglin2-3/+10