aboutsummaryrefslogtreecommitdiff
path: root/gdb/ChangeLog
AgeCommit message (Collapse)AuthorFilesLines
2015-09-21Add two missing constsSimon Marchi1-0/+5
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.
2015-09-21Add NEWS entry for fast tracepoint support on aarch64-linuxPierre Langlois1-0/+4
Here is a NEWS entry for this series: gdb/ChangeLog: * NEWS: Mention support for fast tracepoints on aarch64-linux.
2015-09-21Make aarch64_decode_adrp handle both ADR and ADRP instructionsPierre Langlois1-0/+11
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.
2015-09-21Move instruction decoding into new arch/ directoryPierre Langlois1-0/+47
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.
2015-09-20dwarf2read.c (add_partial_symbol): Remove outdated comments.Doug Evans1-0/+4
gdb/ChangeLog: * dwarf2read.c (add_partial_symbol): Remove outdated comments.
2015-09-20dwarf2_compute_name: add fixme, don't use same name as parameter for localDoug Evans1-0/+5
gdb/ChangeLog: * dwarf2read.c (dwarf2_compute_name): Add FIXME. Don't use a local variable name that collides with a parameter.
2015-09-20crash printing non-local variable from nested subprogramJoel Brobecker1-0/+11
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 63e43d3aedb8b1112899c2d0ad74cbbee687e5d6 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).
2015-09-19Replace current_inferior ()->gdbarch with its wrapper target_gdbarch.Doug Evans1-0/+5
gdb/ChangeLog: * ravenscar-thread.c (ravenscar_inferior_created): Replace current_inferior ()->gdbarch with its wrapper target_gdbarch.
2015-09-18linux-thread-db.c (record_thread): Return the created thread.Doug Evans1-0/+6
gdb/ChangeLog: * linux-thread-db.c (record_thread): Return the created thread. (thread_from_lwp): Likewise. (thread_db_get_thread_local_address): Update.
2015-09-18symtab.h (general_symbol_info) <mangled_lang>: delete and move up only member.Doug Evans1-0/+5
gdb/ChangeLog: * symtab.h (general_symbol_info) <mangled_lang>: Delete struct, move only member demangled_name up. All uses updated.
2015-09-18default_read_var_value <LOC_UNRESOLVED>: Include minsym kind in error message.Doug Evans1-0/+7
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-18aarch64 multi-arch (part 3): get thread areaYao Qi1-0/+10
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.
2015-09-18btrace: honour scheduler-locking for all-stop targetsMarkus Metzger1-0/+4
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.
2015-09-18infrun: scheduler-locking replayMarkus Metzger1-0/+14
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.
2015-09-18target: add to_record_will_replay target methodMarkus Metzger1-0/+11
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>
2015-09-18target: add to_record_stop_replaying target methodMarkus Metzger1-0/+13
Add a new target method to_record_stop_replaying to stop replaying. gdb/ * record-btrace.c (record_btrace_resume): Call target_record_stop_replaying. (record_btrace_stop_replaying_all): New. (init_record_btrace_ops): Initialize to_record_stop_replaying. * record-full.c (record_full_stop_replaying): New. (init_record_full_ops ): Initialize to_record_stop_replaying. * target-delegates.c: Regenerated. * target.c (target_record_stop_replaying): New. * target.h (struct target_ops) <to_record_stop_replaying>: New. (target_record_stop_replaying): New.
2015-09-18btrace: allow full memory and register access for non-replaying threadsMarkus Metzger1-0/+8
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.
2015-09-18target, record: add PTID argument to to_record_is_replayingMarkus Metzger1-0/+13
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.
2015-09-18btrace: non-stopMarkus Metzger1-0/+5
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 Metzger1-0/+5
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 Metzger1-0/+5
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 Metzger1-0/+5
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 Metzger1-0/+7
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 Metzger1-0/+15
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 Metzger1-0/+5
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 Metzger1-0/+7
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 Metzger1-0/+8
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 Metzger1-0/+5
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 Metzger1-0/+9
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 Metzger1-0/+11
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 Metzger1-0/+5
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-15[Ada] Enhance type printing for arrays with variable-sized elementsPierre-Marie de Rodat1-0/+5
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-15Fix PR/18564 - regression in showing __thread so extern variablePhilippe Waroquiers1-0/+7
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-15[AArch64] Use debug_printf instead of fprintf_unfilteredPierre Langlois1-0/+28
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 Kratochvil1-0/+8
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-15Move ChangeLog entry to proper placePedro Alves1-7/+0
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 Alves1-0/+7
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-15Support single step by arch or targetYao Qi1-0/+21
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-15aarch64 multi-arch support (part 2): siginfo fixupYao Qi1-0/+18
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-14Bail out of processing stop if hook-stop resumes target / changes contextPedro Alves1-0/+13
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 Rodat1-0/+5
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 Alves1-0/+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-11Extended-remote exec documentationDon Breazeal1-0/+5
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.
2015-09-11Extended-remote catch execDon Breazeal1-0/+9
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.
2015-09-11Extended-remote follow-execDon Breazeal1-0/+37
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.
2015-09-11[AArch64] Cleanup comments in instruction decoding functionsPierre Langlois1-0/+7
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.
2015-09-11[AArch64] Fix incorrect mask when decoding b.cond instructionPierre Langlois1-0/+4
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.
2015-09-11gdb/18947: [aarch64]Step into shared library is very slow.Mihail-Marian Nistor1-0/+6
Install gdbarch_skip_solib_resolver on aarch64 GNU/Linux gdb/ChangeLog: 2015-09-11 Mihail-Marian Nistor <mihail.nistor@freescale.com> PR gdb/18947 * aarch64-linux-tdep.c: (aarch64_linux_init_abi): Install glibc_skip_solib_resolver as gdbarch_skip_solib_resolver callback. Signed-off-by: Mihail-Marian Nistor <mihail.nistor@freescale.com>
2015-09-10Small refactor in ada-lang.c:scan_discrim_boundSimon Marchi1-0/+5
Factor out common arithmetic operations for clarity. gdb/ChangeLog: * ada-lang.c (scan_discrim_bound): Factor out arithmetic operations.
2015-09-10Constify variables in ada-lang.cSimon Marchi1-0/+9
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.
generated by cgit v1.1 at 2025-03-07 11:35:09 +0000