aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2015-05-13dwarf2read.c (die_needs_namespace): Return 1 for DW_TAG_inlined_subroutine.Martin Galvan2-0/+6
gdb/ChangeLog: * dwarf2read.c (die_needs_namespace): Return 1 for DW_TAG_inlined_subroutine.
2015-05-13revert previous patch, author not setDoug Evans2-6/+0
2015-05-13dwarf2read.c (die_needs_namespace): Return 1 for DW_TAG_inlined_subroutine.Doug Evans2-0/+6
gdb/ChangeLog: * dwarf2read.c (die_needs_namespace): Return 1 for DW_TAG_inlined_subroutine.
2015-05-13Make regcache_cpy_no_passthrough staticJan Kratochvil3-8/+18
regcache_cpy_no_passthrough is no longer used for a standalone call. gdb/ChangeLog 2015-05-13 Jan Kratochvil <jan.kratochvil@redhat.com> * regcache.c (regcache_cpy_no_passthrough): New declaration. (regcache_cpy_no_passthrough): Make it static, add function comment. * regcache.h (regcache_dup, regcache_cpy): Reduce/update their comment. (regcache_cpy_no_passthrough): Remove declaration.
2015-05-13Remove stop_registersJan Kratochvil6-38/+16
Now stop_registers are no longer used and it can be removed. I am not much sure what 'proceed_to_finish' really means now so I make a wild guess while updating comments about it. gdb/ChangeLog 2015-05-13 Jan Kratochvil <jan.kratochvil@redhat.com> * gdbthread.h (struct thread_control_state): Update comment for proceed_to_finish. * infcall.c (run_inferior_call): Update comment about proceed_to_finish. * infcmd.c (get_return_value): Update comment about stop_registers. (finish_forward): Update comment about proceed_to_finish. * infrun.c (stop_registers): Remove. (clear_proceed_status, normal_stop): Remove stop_registers handling. * infrun.h (stop_registers): Remove.
2015-05-13infcall: stop_registers -> register_dummy_frame_dtorJan Kratochvil6-25/+188
With dummy_frame destructors GDB no longer has to use global stop_registers. dummy_frame's registers can be now stored associated with their specific dummy_frame. gdb/ChangeLog 2015-05-13 Jan Kratochvil <jan.kratochvil@redhat.com> * infcall.c (struct dummy_frame_context_saver) (dummy_frame_context_saver_data_free, dummy_frame_context_saver_dtor) (dummy_frame_context_saver_drop, dummy_frame_context_saver_cleanup) (dummy_frame_context_saver_get_regs, dummy_frame_context_saver_setup): New. (call_function_by_hand_dummy): Move discard_cleanups of inf_status_cleanup before dummy_frame_push. Call dummy_frame_context_saver_setup and prepare context_saver_cleanup. Use dummy_frame_context_saver_get_regs instead of stop_registers. * infcall.h (struct dummy_frame_context_saver) (dummy_frame_context_saver_drop, dummy_frame_context_saver_cleanup) (dummy_frame_context_saver_get_regs, dummy_frame_context_saver_setup): New declarations. * infcmd.c: Include infcall.h. (get_return_value): Add parameter ctx_saver, use it instead of stop_registers. (print_return_value): Add parameter ctx_saver, pass it. (struct finish_command_continuation_args): Add field ctx_saver. (finish_command_continuation): Update print_return_value caller. (finish_command_continuation_free_arg): Free also ctx_saver. (finish_forward): Call dummy_frame_context_saver_setup. * inferior.h (struct dummy_frame_context_saver): New declaration. (get_return_value): Add parameter ctx_saver. * python/py-finishbreakpoint.c (bpfinishpy_pre_stop_hook): Update get_return_value caller.
2015-05-13register_dummy_frame_dtor: Permit multiple dtorsJan Kratochvil3-18/+62
Later patch needs two independent destructors for the same dummy_frame. Therefore the registrar has been extended to an arbitrary number of destructors. gdb/ChangeLog 2015-05-13 Jan Kratochvil <jan.kratochvil@redhat.com> * dummy-frame.c (struct dummy_frame_dtor_list): New. (struct dummy_frame): Replace dtor and dtor_data by dtor_list. (remove_dummy_frame): Process dtor_list. (pop_dummy_frame): Process dtor_list. (register_dummy_frame_dtor): Maintain dtor_list. (find_dummy_frame_dtor): Handle dtor_list. * dummy-frame.h (register_dummy_frame_dtor, find_dummy_frame_dtor): Update comments.
2015-05-13Call dummy_frame_dtor_ftype also from remove_dummy_frameJan Kratochvil4-7/+23
There was now a leak-like bug that if dummy_frame "disappeared" by remove_dummy_frame then its destructor was not called. For example in the case of 'compile code' dummy frames the injected objfile would never get freed after some inferior longjmp out of the injected code. gdb/ChangeLog 2015-05-13 Jan Kratochvil <jan.kratochvil@redhat.com> * compile/compile-object-run.c (do_module_cleanup): Add parameter registers_valid. (compile_object_run): Update do_module_cleanup caller. * dummy-frame.c: Include infcall.h. (struct dummy_frame): Update dtor comment. (remove_dummy_frame): Call dtor. (pop_dummy_frame): Update dtor caller. * dummy-frame.h (dummy_frame_dtor_ftype): Add parameter registers_valid.
2015-05-13Document the GDB 7.9.1 release in gdb/ChangeLogJoel Brobecker1-0/+4
gdb/ChangeLog: GDB 7.9.1 released.
2015-05-13gdb/NEWS: Move "Xmethods can now specify a result type" to GDB 7.9.1 section.Joel Brobecker2-1/+12
As this change was ported to GDB 7.9.1, the NEWS entry is moved to a newly-created "Changes in GDB 7.9.1" section, matching the NEWS file which is going to be distributed with the GDB 7.9.1 release. gdb/ChangeLog: * NEWS: Create "Changes in GDB 7.9.1" section. Move news about Xmethods now being able to specify a result type to that new section.
2015-05-13Add missing ChangeLog entry for previous commitPatrick Palka1-1/+7
2015-05-13Avoid race condition when handling a SIGWINCH signalPatrick Palka2-2/+2
The control variable win_resized must be cleared before responding to it. Otherwise there is a small window where another SIGWINCH might occur in between the handling of an earlier SIGWINCH and the clearing of win_resized, at which point win_resized would be set (again) by the signal handler. Shortly thereafter we would clear win_resized even though we only handled the earlier SIGWINCH but not the latest one. This chain of events is all avoided if we clear win_resized first. gdb/ChangeLog: * tui/tui-win.c (tui_async_resize_screen): Clear win_resized first before resizing the window. * tui.c (tui_enable): Likewise.
2015-05-13dummy_frame_dtor_ftype vs. call_function_by_hand_dummy_dtor_ftype cleanupJan Kratochvil5-5/+19
Both dummy_frame_dtor_ftype and call_function_by_hand_dummy_dtor_ftype represent the same type, there was some mistake/duplication during check-in. gdb/ChangeLog 2015-05-08 Jan Kratochvil <jan.kratochvil@redhat.com> * dummy-frame.c (struct dummy_frame): Use proper typedef for dtor. * dummy-frame.h (dummy_frame_dtor_ftype): Add its comment. * infcall.c (call_function_by_hand_dummy): Use proper typedef for dummy_dtor parameter. * infcall.h: Include dummy-frame.h. (call_function_by_hand_dummy_dtor_ftype): Remove. (call_function_by_hand_dummy): Use proper typedef for dummy_dtor parameter.
2015-05-13Fix PR gdb/17820Patrick Palka6-30/+95
This patch is a comprehensive fix for PR 17820 which reports that using "set history size unlimited" inside one's gdbinit file doesn't really work. There are three small changes in this patch. The most important change this patch makes is to decode the argument of the "size" subcommand using add_setshow_zuinteger_unlimited_cmd() instead of using add_setshow_uinteger_cmd(). The new decoder takes an int * and maps unlimited to -1 whereas the old decoder takes an unsigned int * and maps unlimited to UINT_MAX. Using the new decoder simplifies our handling of unlimited and makes it easier to interface with readline which itself expects a signed-int history size. The second change is the factoring of the [stifle|unstifle]_history logic into a common function which is now used by both init_history() and set_history_size_command(). This is technically the change that fixes the PR itself. Thirdly, this patch initializes history_size_setshow_var to -2 to mean that the variable has not been set yet. Now init_history() tests for -2 instead of 0 to determine whether to give the variable a default value. This means that having "set history size 0" in one's gdbinit file will actually keep the history size at 0 and not reset it to 256. gdb/ChangeLog: PR gdb/17820 * top.c (history_size_setshow_var): Change type to signed. Initialize to -2. Update documentation. (set_readline_history_size): Define. (set_history_size_command): Use it. Remove logic for handling out-of-range sizes. (init_history): Use set_readline_history_size(). Test for a value of -2 instead of 0 when determining whether to set a default history size. (init_main): Decode the argument of the "size" command as a zuinteger_unlimited. gdb/testsuite/ChangeLog: PR gdb/17820 * gdb.base/gdbinit-history.exp: New test. * gdb.base/gdbinit-history/unlimited/.gdbinit: New file. * gdb.base/gdbinit-history/zero/.gdbinit: New file.
2015-05-12tweak some commentsDoug Evans2-4/+10
gdb/ChangeLog: * dwarf2read.c (struct file_entry): Tweak comments. (get_debug_line_section): Tweak comments.
2015-05-12Extended-remote fork event docsDon Breazeal4-0/+124
This patch contains the accumulated documentation changes for the rest of the extended-remote follow fork patchset. gdb/ChangeLog: * NEWS: Announce fork support in the RSP and support for fork debugging in extended mode. gdb/doc/ChangeLog: * gdb.texinfo (Forks): Note that fork debugging is supported in extended mode. (Remote Configuration): Add fork event features to table of packet settings. (Stop Reply Packets): Add fork events to list of stop reasons. (General Query Packets): Add fork events to tables of 'gdbfeatures' and 'stub features' supported in the qSupported packet, as well as to the list containing stub feature details.
2015-05-12Extended-remote fork catchDon Breazeal2-3/+241
This patch implements catchpoints for fork events on extended-remote Linux targets. Implementation appeared to be straightforward, requiring four new functions in remote.c to implement insert/remove of fork/vfork catchpoints. These functions are essentially stubs that just return 0 ('success') if the required features are enabled. If the fork events are being reported, then catchpoints are set and hit. However, there are some extra issues that arise with catchpoints. 1) Thread creation reporting -- fork catchpoints are hit before the follow_fork has been completed. When stopped at a fork catchpoint in the native implementation, the new process is not 'reported' until after the follow is done. It doesn't show up in the inferiors list or the threads list. However, in the gdbserver case, an 'info threads' while stopped at a fork catchpoint will retrieve the new thread info from the target and add it to GDB's data structures, prior to the follow operations. Because of this premature report, things on the GDB side eventually get very confused. So in remote.c:remote_update_thread_list, we check to see if there are any pending fork parent threads. If there are we remove the related fork child thread from the thread list sent by the target. 2) Kill process before fork is followed -- on the native side in linux-nat.c:linux_nat_kill, there is some code to handle the case where a fork has occurred but follow_fork hasn't been called yet. It does this by using the last status to determine if a follow is pending, and if it is, to kill the child task. The use of last_status is fragile in situations like non-stop mode where other events may have occurred after the fork event. This patch identifies a fork parent in remote.c:extended_remote_kill in a way similar to that used in thread creation reporting above. If one is found, it kills the new child as well. Tested on x64 Ubuntu Lucid, native, remote, extended-remote. Tested the case of killing the forking process before the fork has been followed manually. gdb/ChangeLog: * remote.c (remote_insert_fork_catchpoint): New function. (remote_remove_fork_catchpoint): New function. (remote_insert_vfork_catchpoint): New function. (remote_remove_vfork_catchpoint): New function. (pending_fork_parent_callback): New function. (remove_new_fork_child): New function. (remote_update_thread_list): Call remote_notif_get_pending_events and remove_new_fork_child. (extended_remote_kill): Kill fork child when killing the parent before follow_fork completes. (init_extended_remote_ops): Initialize target vector with new fork catchpoint functions.
2015-05-12Extended-remote follow vforkDon Breazeal6-7/+78
This patch implements follow-fork for vfork on extended-remote Linux targets. The implementation follows the native implementation as much as possible. Most of the work is done on the GDB side in the existing code now in infrun.c. GDBserver just has to report the events and do a little bookkeeping. Implementation includes: * enabling VFORK events by adding ptrace options for VFORK and VFORK_DONE to linux-low.c:linux_low_ptrace_options. * handling VFORK and VFORK_DONE events in linux-low.c:handle_extended_wait and reporting them to GDB. * including VFORK and VFORK_DONE events in the predicate linux-low.c:extended_event_reported. * adding support for VFORK and VFORK_DONE events in RSP by adding stop reasons "vfork" and "vforkdone" to the 'T' Stop Reply Packet in both gdbserver/remote-utils.c and gdb/remote.c. Tested on x64 Ubuntu Lucid, native, remote, extended-remote. gdb/gdbserver/ChangeLog: * linux-low.c (handle_extended_wait): Handle PTRACE_EVENT_FORK and PTRACE_EVENT_VFORK_DONE. (linux_low_ptrace_options, extended_event_reported): Add vfork events. * remote-utils.c (prepare_resume_reply): New stop reasons "vfork" and "vforkdone" for RSP 'T' Stop Reply Packet. * server.h (report_vfork_events): Declare global variable. gdb/ChangeLog: * remote.c (remove_vfork_event_p): New function. (remote_follow_fork): Add vfork event type to event checking. (remote_parse_stop_reply): New stop reasons "vfork" and "vforkdone" for RSP 'T' Stop Reply Packet.
2015-05-12Arch-specific remote follow forkDon Breazeal7-12/+187
This patch implements the architecture-specific pieces of follow-fork for remote and extended-remote Linux targets, which in the current implementation copyies the parent's debug register state into the new child's data structures. This is required for x86, arm, aarch64, and mips. This follows the native implementation as closely as possible by implementing a new linux_target_ops function 'new_fork', which is analogous to 'linux_nat_new_fork' in linux-nat.c. In gdbserver, the debug registers are stored in the process list, instead of an architecture-specific list, so the function arguments are process_info pointers instead of an lwp_info and a pid as in the native implementation. In the MIPS implementation the debug register mirror is stored differently from x86, ARM, and aarch64, so instead of doing a simple structure assignment I had to clone the list of watchpoint structures. Tested using gdb.threads/watchpoint-fork.exp on x86, and ran manual tests on a MIPS board and an ARM board. Aarch64 hasn't been tested. gdb/gdbserver/ChangeLog: * linux-aarch64-low.c (aarch64_linux_new_fork): New function. (the_low_target) <new_fork>: Initialize new member. * linux-arm-low.c (arm_new_fork): New function. (the_low_target) <new_fork>: Initialize new member. * linux-low.c (handle_extended_wait): Call new target function new_fork. * linux-low.h (struct linux_target_ops) <new_fork>: New member. * linux-mips-low.c (mips_add_watchpoint): New function extracted from mips_insert_point. (the_low_target) <new_fork>: Initialize new member. (mips_linux_new_fork): New function. (mips_insert_point): Call mips_add_watchpoint. * linux-x86-low.c (x86_linux_new_fork): New function. (the_low_target) <new_fork>: Initialize new member.
2015-05-12Extended-remote Linux follow forkDon Breazeal14-106/+415
This patch implements basic support for follow-fork and detach-on-fork on extended-remote Linux targets. Only 'fork' is supported in this patch; 'vfork' support is added n a subsequent patch. This patch depends on the previous patches in the patch series. Sufficient extended-remote functionality has been implemented here to pass gdb.base/multi-forks.exp, as well as gdb.base/foll-fork.exp with the catchpoint tests commented out. Some other fork tests fail with this patch because it doesn't provide the architecture support needed for watchpoint inheritance or fork catchpoints. The implementation follows the same general structure as for the native implementation as much as possible. This implementation includes: * enabling fork events in linux-low.c in initialize_low and linux_enable_extended_features * handling fork events in gdbserver/linux-low.c:handle_extended_wait - when a fork event occurs in gdbserver, we must do the full creation of the new process, thread, lwp, and breakpoint lists. This is required whether or not the new child is destined to be detached-on-fork, because GDB will make target calls that require all the structures. In particular we need the breakpoint lists in order to remove the breakpoints from a detaching child. If we are not detaching the child we will need all these structures anyway. - as part of this event handling we store the target_waitstatus in a new member of the parent lwp_info structure, 'waitstatus'. This is used to store extended event information for reporting to GDB. - handle_extended_wait is given a return value, denoting whether the handled event should be reported to GDB. Previously it had only handled clone events, which were never reported. * using a new predicate in gdbserver to control handling of the fork event (and eventually all extended events) in linux_wait_1. The predicate, extended_event_reported, checks a target_waitstatus.kind for an extended ptrace event. * implementing a new RSP 'T' Stop Reply Packet stop reason: "fork", in gdbserver/remote-utils.c and remote.c. * implementing new target and RSP support for target_follow_fork with target extended-remote. (The RSP components were actually defined in patch 1, but they see their first use here). - remote target routine remote_follow_fork, which just sends the 'D;pid' detach packet to detach the new fork child cleanly. We can't just call target_detach because the data structures for the forked child have not been allocated on the host side. Tested on x64 Ubuntu Lucid, native, remote, extended-remote. gdb/gdbserver/ChangeLog: * linux-low.c (handle_extended_wait): Implement return value, rename argument 'event_child' to 'event_lwp', handle PTRACE_EVENT_FORK, call internal_error for unrecognized event. (linux_low_ptrace_options): New function. (linux_low_filter_event): Call linux_low_ptrace_options, use different argument fo linux_enable_event_reporting, use return value from handle_extended_wait. (extended_event_reported): New function. (linux_wait_1): Call extended_event_reported and set status to report fork events. (linux_write_memory): Add pid to debug message. (reset_lwp_ptrace_options_callback): New function. (linux_handle_new_gdb_connection): New function. (linux_target_ops): Initialize new structure member. * linux-low.h (struct lwp_info) <waitstatus>: New member. * lynx-low.c: Initialize new structure member. * remote-utils.c (prepare_resume_reply): Implement stop reason "fork" for "T" stop message. * server.c (handle_query): Call handle_new_gdb_connection. * server.h (report_fork_events): Declare global flag. * target.h (struct target_ops) <handle_new_gdb_connection>: New member. (target_handle_new_gdb_connection): New macro. * win32-low.c: Initialize new structure member. gdb/ChangeLog: * linux-nat.c (linux_nat_ptrace_options): New function. (linux_init_ptrace, wait_lwp, linux_nat_filter_event): Call linux_nat_ptrace_options and use different argument to linux_enable_event_reporting. (_initialize_linux_nat): Delete call to linux_ptrace_set_additional_flags. * nat/linux-ptrace.c (current_ptrace_options): Rename to supported_ptrace_options. (additional_flags): Delete variable. (linux_check_ptrace_features): Use supported_ptrace_options. (linux_test_for_tracesysgood, linux_test_for_tracefork): Likewise, and remove additional_flags check. (linux_enable_event_reporting): Change 'attached' argument to 'options'. Use supported_ptrace_options. (ptrace_supports_feature): Change comment. Use supported_ptrace_options. (linux_ptrace_set_additional_flags): Delete function. * nat/linux-ptrace.h (linux_ptrace_set_additional_flags): Delete function prototype. * remote.c (remote_fork_event_p): New function. (remote_detach_pid): New function. (remote_detach_1): Call remote_detach_pid, don't mourn inferior if doing detach-on-fork. (remote_follow_fork): New function. (remote_parse_stop_reply): Handle new "T" stop reason "fork". (remote_pid_to_str): Print "process" strings for pid/0/0 ptids. (init_extended_remote_ops): Initialize to_follow_fork.
2015-05-12Clone remote breakpointsDon Breazeal3-0/+119
This patch implements gdbserver routines to clone the breakpoint lists of a process, duplicating them for another process. In gdbserver, each process maintains its own independent breakpoint list. When a fork call creates a child, all of the breakpoints currently inserted in the parent process are also inserted in the child process, but there is nothing to describe them in the data structures related to the child. The child must have a breakpoint list describing them so that they can be removed (if detaching) or recognized (if following). Implementation is a mechanical process of just cloning the lists in several new functions in gdbserver/mem-break.c. Tested by building, since none of the new functions are called yet. This was tested with another patch in the series that implements follow-fork. gdb/gdbserver/ChangeLog: * mem-break.c (APPEND_TO_LIST): Define macro. (clone_agent_expr): New function. (clone_one_breakpoint): New function. (clone_all_breakpoints): New function. * mem-break.h: Declare new functions.
2015-05-12Identify remote fork event supportDon Breazeal10-1/+120
This patch implements a mechanism for GDB to determine whether fork events are supported in gdbserver. This is a preparatory patch for remote fork and exec event support. Two new RSP packets are defined to represent fork and vfork event support. These packets are used just like PACKET_multiprocess_feature to denote whether the corresponding event is supported. GDB sends fork-events+ and vfork-events+ to gdbserver to inquire about fork event support. If the response enables these packets, then GDB knows that gdbserver supports the corresponding events and will enable them. Target functions used to query for support are included along with each new packet. In order for gdbserver to know whether the events are supported at the point where the qSupported packet arrives, the code in nat/linux-ptrace.c had to be reorganized. Previously it would test for fork/exec event support, then enable the events using the pid of the inferior. When the qSupported packet arrives there may not be an inferior. So the mechanism was split into two parts: a function that checks whether the events are supported, called when gdbserver starts up, and another that enables the events when the inferior stops for the first time. Another gdbserver change was to add some global variables similar to multi_process, one per new packet. These are used to control whether the corresponding fork events are enabled. If GDB does not inquire about the event support in the qSupported packet, then gdbserver will not set these "report the event" flags. If the flags are not set, the events are ignored like they were in the past. Thus, gdbserver will never send fork event notification to an older GDB that doesn't recognize fork events. Tested on Ubuntu x64, native/remote/extended-remote, and as part of subsequent patches in the series. gdb/gdbserver/ChangeLog: * linux-low.c (linux_supports_fork_events): New function. (linux_supports_vfork_events): New function. (linux_target_ops): Initialize new structure members. (initialize_low): Call linux_check_ptrace_features. * lynx-low.c (lynx_target_ops): Initialize new structure members. * server.c (report_fork_events, report_vfork_events): New global flags. (handle_query): Add new features to qSupported packet and response. (captured_main): Initialize new global variables. * target.h (struct target_ops) <supports_fork_events>: New member. <supports_vfork_events>: New member. (target_supports_fork_events): New macro. (target_supports_vfork_events): New macro. * win32-low.c (win32_target_ops): Initialize new structure members. gdb/ChangeLog: * nat/linux-ptrace.c (linux_check_ptrace_features): Change from static to extern. * nat/linux-ptrace.h (linux_check_ptrace_features): Declare. * remote.c (anonymous enum): <PACKET_fork_event_feature, * PACKET_vfork_event_feature>: New enumeration constants. (remote_protocol_features): Add table entries for new packets. (remote_query_supported): Add new feature queries to qSupported packet. (_initialize_remote): Exempt new packets from the requirement to have 'set remote' commands.
2015-05-12Locate executables on remote stubs without multiprocess extensionsGary Benson6-9/+54
This commit allows GDB to determine filenames of main executables when debugging using remote stubs without multiprocess extensions. The qXfer:exec-file:read packet is extended to allow an empty annex, with the meaning that the remote stub should supply the filename of whatever it thinks is the current process. gdb/ChangeLog: * remote.c (remote_add_inferior): Call exec_file_locate_attach for fake PIDs as well as real ones. (remote_pid_to_exec_file): Send empty annex if PID is fake. gdb/doc/ChangeLog: * gdb.texinfo (General Query Packets): Document qXfer:exec-file:read with empty annex. gdb/gdbserver/ChangeLog: * server.c (handle_qxfer_exec_file): Use current process if annex is empty.
2015-05-09[Python] Add methods reference_value and const_value to gdb.Value.Siva Chandra11-1/+135
gdb/ChangeLog: * NEWS (Python Scripting): Mention the new gdb.Value methods. * python/py-value.c (valpy_reference_value): New function. (valpy_const_value): Likewise. (value_object_methods): Add new methods. * value.c (make_cv_value): New function. * value.h (make_cv_value): Declare. gdb/doc/ChangeLog: * python.texi (Values From Inferior): Add descriptions of new methods gdb.Value.reference_value and gdb.Value.const_value. gdb/testsuite/ChangeLog: * gdb.python/py-xmethods.cc: Enhance test case. * gdb.python/py-xmethods.exp: New tests. * gdb.python/py-xmethods.py (A_indexoper): New xmethod worker function. (B_indexoper): Likewise. (global_dm_list) : Add new xmethod worker functions.
2015-05-08Avoid segfault on missing directory table.Sandra Loosemore2-6/+17
2015-05-08 Yao Qi <yao@codesourcery.com> Sandra Loosemore <sandra@codesourcery.com> gdb/ * dwarf2read.c (setup_type_unit_groups): Do NULL pointer check to 'lh->include_dirs' before accessing to it. (psymtab_include_file_name): Likewise. (dwarf_decode_lines_1): Likewise. (dwarf_decode_lines): Likewise. (file_file_name): Likewise.
2015-05-08Fix register save offset for nios2 signal handler trampolines.Sandra Loosemore2-2/+28
2015-05-08 Sandra Loosemore <sandra@codesourcery.com> gdb/ * nios2-linux-tdep.c (NIOS2_SIGRETURN_TRAMP_ADDR): Define. (NIOS2_SIGRETURN_REGSAVE_OFFSET): Define. (nios2_linux_rt_sigreturn_init): Adjust base address of register save area.
2015-05-08Use PTRACE_GETREGSET/SETREGSET in nios2 gdbserver.Sandra Loosemore2-7/+11
2015-05-08 Sandra Loosemore <sandra@codesourcery.com> gdb/gdbserver/ * linux-nios2-low.c: Include elf/common.h. Adjust comments. Remove HAVE_PTRACE_GETREGS conditionals. (nios2_regsets): Use PTRACE_GETREGSET and PTRACE_SETREGSET instead of PTRACE_GETREGS and PTRACE_SETREGS.
2015-05-08Revert to using "trap 31" for breakpoints on nios2.Sandra Loosemore2-6/+19
2015-05-08 Sandra Loosemore <sandra@codesourcery.com> gdb/ * nios2-tdep.c (nios2_breakpoint_from_pc): Revert to using "trap 31" as the breakpoint instruction on all targets.
2015-05-08Fix coredump-filter.exp by correctly unsetting arraySergio Durigan Junior2-1/+6
In my last commit to make gdb.base/coredump-filter.exp be more robust regarding using arrays in the global namespace, I cleared the "coredump_var_addr" array like this: set coredump_var_addr "" # use coredump_var_addr as an array... This causes DejaGNU to complain because the variable is first set as non-array, and the used as an array. The correct way to do this is to unset the variable using: unset -nocomplain coredump_var_addr # use coredump_var_addr as an array... The "-nocomplain" part is necessary because if the variable doesn't exist "unset" will not error. Tested on Fedora 20 x86_64. gdb/testsuite/ChangeLog: 2015-05-08 Sergio Durigan Junior <sergiodj@redhat.com> * gdb.base/coredump-filter.exp: Correctly unset "coredump_var_addr" array.
2015-05-08Fix sequential gdb test runsPedro Alves2-0/+8
Sequential test runs are stopping prematurely like this: $ make check RUNTESTFLAGS="non-existing-program.exp server-exec-info.exp" Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.server/non-existing-program.exp ... Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.server/server-exec-info.exp ... can not find channel named "exp6" while executing "match_max [match_max -d]" (procedure "default_gdb_init" line 26) invoked from within "default_gdb_init $test_file_name" (procedure "gdb_init" line 83) invoked from within "${tool}_init $test_file_name" (procedure "runtest" line 18) invoked from within "runtest $test_name" ("foreach" body line 42) invoked from within ... make[2]: *** [check-single] Error 1 make[2]: Leaving directory `/home/pedro/gdb/mygit/build/gdb/testsuite' make[1]: *** [check] Error 2 make[1]: Leaving directory `/home/pedro/gdb/mygit/build/gdb/testsuite' make: *** [check] Error 2 default_gdb_init has this: # Unlike most tests, we have a small number of tests that generate # a very large amount of output. We therefore increase the expect # buffer size to be able to contain the entire test output. This # is especially needed by gdb.base/info-macros.exp. match_max -d 65536 # Also set this value for the currently running GDB. match_max [match_max -d] It's the second match_max that is erroring. As that call does not specify an explicit channel name with -i, expect defaults to $spawn_id, which is pointing at a channel that is already gone. (If the spawn_id variable is not set, match_max defaults to $user_spawn_id / stdin/out). gdb/testsuite/ChangeLog: 2015-05-08 Pedro Alves <palves@redhat.com> * gdb.server/non-existing-program.exp: Unset spawn_id.
2015-05-08Remove unused declaration of print_return_value.Jan Kratochvil2-3/+4
gdb/ChangeLog 2015-05-08 Jan Kratochvil <jan.kratochvil@redhat.com> * infcmd.c (print_return_value): Remove unused declaration.
2015-05-08Problem printing record with array whose upper bound is record componentJoel Brobecker2-2/+8
Consider the following declarations... type Obj_T (Selected_Flights_Length : Natural) is record Selected_Flights : Flights.List.T (1 .. Selected_Flights_Length); end record; Broken : Obj_T; ... which defines a variable named "broken" which is a discrimated record where broken.Selected_Flights is an array whose upper bound is stored in the record's Selected_Flights_Length component. Trying to print the value of that object currently fails: (gdb) print broken cannot find reference address for offset property Looking at the debugging info, we see that variable "Broken" is a reference... <1><8e3>: Abbrev Number: 21 (DW_TAG_const_type) <8e4> DW_AT_type : <0x8e8> <1><8e8>: Abbrev Number: 22 (DW_TAG_reference_type) <8e9> DW_AT_byte_size : 8 <8ea> DW_AT_type : <0x7ec> ... to ... <1><7ec>: Abbrev Number: 12 (DW_TAG_structure_type) <7ed> DW_AT_name : (indirect string, offset: 0xc6d): reprod__obj_t <7f1> DW_AT_decl_file : 2 <7f2> DW_AT_decl_line : 15 <7f3> DW_AT_GNAT_descriptive_type: <0x87e> <7f7> DW_AT_sibling : <0x87e> ... which has 2 members, the first one being the discriminant... <2><7fb>: Abbrev Number: 9 (DW_TAG_member) <7fc> DW_AT_name : (indirect string, offset: 0xc98): selected_flights_length <800> DW_AT_decl_file : 2 <801> DW_AT_decl_line : 15 <802> DW_AT_type : <0x807> <806> DW_AT_data_member_location: 0 ... and the second one being the one that causes trouble... <2><83d>: Abbrev Number: 9 (DW_TAG_member) <83e> DW_AT_name : (indirect string, offset: 0xd17): selected_flights <842> DW_AT_decl_file : 2 <843> DW_AT_decl_line : 17 <844> DW_AT_type : <0x815> <848> DW_AT_data_member_location: 4 The second field's type is an array.... <2><815>: Abbrev Number: 14 (DW_TAG_array_type) <816> DW_AT_name : (indirect string, offset: 0xd2f): reprod__obj_t__T5sP <81a> DW_AT_GNAT_descriptive_type: <0x7e1> <81e> DW_AT_type : <0x748> <822> DW_AT_sibling : <0x830> ... whose uppper bound is a reference to <0x7fb>... <3><826>: Abbrev Number: 15 (DW_TAG_subrange_type) <827> DW_AT_type : <0x830> <82b> DW_AT_upper_bound : <0x7fb> <3><82f>: Abbrev Number: 0 Because the upper bound is dynamic, we try to resolve it. As it happens, the upper-bound resolution for this range type works fine. What breaks is when we try to resolve this range type's target type, which is: <2><830>: Abbrev Number: 16 (DW_TAG_subrange_type) <831> DW_AT_upper_bound : <0x7fb> <835> DW_AT_name : (indirect string, offset: 0xc7b): reprod__obj_t__T4s___XDLU_1__selected_flights_length <839> DW_AT_type : <0x766> <83d> DW_AT_artificial : 1 It is actually pretty much the same as the first subrange type, so you might ask why this is causing trouble, when the resolution of the previous DIE worked like a charm??? Well, for that, we need to backtrack a bit, and notice that, ahead of the DW_TAG_structure_type's DIE, there is the following DIE: <1><7e1>: Abbrev Number: 6 (DW_TAG_typedef) <7e2> DW_AT_name : (indirect string, offset: 0xbae): reprod__obj_t__T5s <7e6> DW_AT_decl_file : 2 <7e7> DW_AT_decl_line : 17 <7e8> DW_AT_type : <0x849> ... and that DIE references an array type... <2><849>: Abbrev Number: 14 (DW_TAG_array_type) <84a> DW_AT_name : (indirect string, offset: 0xbae): reprod__obj_t__T5s <84e> DW_AT_GNAT_descriptive_type: <0x864> <852> DW_AT_type : <0x748> <856> DW_AT_sibling : <0x864> ... whose subrange is... <3><85a>: Abbrev Number: 15 (DW_TAG_subrange_type) <85b> DW_AT_type : <0x830> <85f> DW_AT_upper_bound : <0x7fb> ... where the subrange's base type is the DW_TAG_subrange_type DIE that is causing problem. In summary, we process the typedef first, which causes us to process the second subrange BEFORE we process the struct DIE itself, and therefore the struct's discriminent (DW_TAG_member #1). As a result, while trying to handle the reference to that DW_TAG_member #1 as the upper bound of the second range type, we do... case DW_AT_data_member_location: { [...] baton->referenced_type = get_die_type (target_die->parent, target_cu); ... where target_die->parent (DW_TAG_member #1) hasn't been processed yet, and thus get_die_type returns NULL. This is what later causes us problems trying to find the right address to use as the base address for our field, which then triggers the error message we are seeing. This patch fixes the issue by calling read_type_die instead of get_die_type. If the DIE has already been processed, then this is the same as get_die_type. If not, the it'll get the parent die to be read, and then get its type. gdb/ChangeLog: * dwarf2read.c (attr_to_dynamic_prop) <DW_AT_data_member_location>: Use read_type_die isntead of get_die_type. Tested on x86_64-linux, no regression. No testcase, unfortunately, as the reproducer was given to us by a customer, and it's been otherwise surprisingly difficult to reproduce the same error outside of that reproducer.
2015-05-08[Ada] error trying to call function when parameter is aligner type.Joel Brobecker2-0/+15
We observed on x86-windows that trying to call a function from GDB leads to a mysterious "Invalid cast" error. This can be observed in gdb.ada/float_param.exp: (gdb) call set_long_double(1, global_small_struct, 4.0) Invalid cast. This happens because the 3rd parameter, a Long_Long_Float, is actually passed wrapped inside a PAD structure. As documented in GNAT's exp_dbug.ads, PAD types are simple wrappers that GNAT uses to handle types with size or alignment constraints. We already support those when printing an object encapsulated in a PAD type, but not when trying to pass an argument that is wrapped inside a PAD type. As a result, what happens is that call_function_by_hand ends up with an argument with a type that looks incompatible with the expected type of the argument. The error comes when trying to push the arguments in inferior memory, while trying to coerce each one of them to their expected types (in value_arg_coerce). Note that the problem is not specific to Windows, but so far, this is the only platform where we've seen this happen. gdb/ChangeLog: * ada-lang.c (ada_convert_actual): Add handling of formals passed inside an aligner type. Tested on x86-windows (AdaCore testsuite) and x86_64-linux (official testsuite as well as AdaCore's testsuite).
2015-05-08gdb/copyright.py: Remove sim/erc32 files from NOT_FSF_LIST.Joel Brobecker2-3/+4
Now that the erc32 files have been updated to contain an FSF copyright header, these files should no longer be in the exclude list. gdb/ChangeLog: * copyright.py (NOT_FSF_LIST): Remove sim/erc32 entries.
2015-05-08[PR python/18291] Fix printing of "disabled" status of xmethod matchers.Siva Chandra4-2/+16
gdb/ChangeLog: PR python/18291 * python/lib/gdb/command/xmethods.py (print_xm_info): Fix typo. Print xmethod matcher status. gdb/testsuite/ChangeLog: PR python/18291 * gdb.python/py-xmethods.exp: Add tests.
2015-05-08Fix PR 18208: update /proc/pid/coredump_filter by c codeYao Qi3-9/+31
Hi, We see some fails in gdb.base/coredump-filter.exp when we do remote gdbserver testing, like what I did for arm/aarch64 linux testing or run it with board file remote-gdbserver-on-localhost $ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost coredump-filter.exp' we find that this line in the test doesn't work as expected, remote_exec target "sh -c \"echo $filter_flag > /proc/$ipid/coredump_filter\"" although such pattern has been used in gdb testsuite somewhere else, but the special thing here is that we redirect the output to /proc/$ipid/coredump_filter on the remote target. DejaGNU will redirect the output from the remote target to local, and looks tcl gets confused by these two redirection. After trying pass different parameters to remote_exec and hacking remote_exec/rsh_exec/local_exec, I got no success, I decide to give up, and try to update /proc/$ipid/coredump_filter by the c code directly. This patch adds a c function set_coredump_filter to update coredump_filter, and GDB calls it. gdb/testsuite: 2015-05-08 Yao Qi <yao.qi@linaro.org> PR gdb/18208 * gdb.base/coredump-filter.c (set_coredump_filter): New function. * gdb.base/coredump-filter.exp (do_save_core): Call inferior function set_coredump_filter, and remove remote_exec call. Remove argument ipid. Callers update. (top level): Don't get inferior's PID.
2015-05-08[gdbserver] Disable conditional breakpoints on no-hardware-single-step targetsYao Qi8-1/+53
GDBserver steps over breakpoint if the condition is false, but if target doesn't support hardware single step, the step over is very simple, if not incorrect, in linux-arm-low.c: /* We only place breakpoints in empty marker functions, and thread locking is outside of the function. So rather than importing software single-step, we can just run until exit. */ static CORE_ADDR arm_reinsert_addr (void) { struct regcache *regcache = get_thread_regcache (current_thread, 1); unsigned long pc; collect_register_by_name (regcache, "lr", &pc); return pc; } and linux-mips-low.c does the same. GDBserver sets a breakpoint at the return address of the current function, resume and wait the program hits the breakpoint in order to achieve "breakpoint step over". What if program hits other user breakponits during this "step over"? It is worse if the arm/thumb interworking is considered. Nowadays, GDBserver arm backend unconditionally inserts arm breakpoint, /* Define an ARM-mode breakpoint; we only set breakpoints in the C library, which is most likely to be ARM. If the kernel supports clone events, we will never insert a breakpoint, so even a Thumb C library will work; so will mixing EABI/non-EABI gdbserver and application. */ (const unsigned char *) &arm_breakpoint, (const unsigned char *) &arm_eabi_breakpoint, note that the comments are no longer valid as C library can be compiled in thumb mode. When GDBserver steps over a breakpoint in arm mode function, which returns to thumb mode, GDBserver will insert arm mode breakpoint by mistake and the program will crash. GDBserver alone is unable to determine the arm/thumb mode given a PC address. See how GDB does it in arm-tdep.c:arm_pc_is_thumb. After thinking about how to teach GDBserver inserting right breakpoint (arm or thumb) for a while, I reconsider it from a different direction that it may be unreasonable to run target-side conditional breakpoint for targets without hardware single step. Pedro also pointed this out here https://sourceware.org/ml/gdb-patches/2015-04/msg00337.html This patch is to add a new target_ops hook supports_conditional_breakpoints, and only reply ";ConditionalBreakpoints+" if it is true. On linux targets, supports_conditional_breakpoints returns true if target has hardware single step, on other targets, (win32, lynx, nto, spu), set it to NULL, because conditional breakpoint is a linux-specific feature. gdb/gdbserver: 2015-05-08 Yao Qi <yao.qi@linaro.org> * linux-low.c (linux_supports_conditional_breakpoints): New function. (linux_target_ops): Install new target method. * lynx-low.c (lynx_target_ops): Install NULL hook for supports_conditional_breakpoints. * nto-low.c (nto_target_ops): Likewise. * spu-low.c (spu_target_ops): Likewise. * win32-low.c (win32_target_ops): Likewise. * server.c (handle_query): Check target_supports_conditional_breakpoints. * target.h (struct target_ops) <supports_conditional_breakpoints>: New field. (target_supports_conditional_breakpoints): New macro.
2015-05-08S390: Fix for inadvertently setting 24-bit mode in fill_gregsetAndreas Arnez2-9/+25
On 64-bit S390 platforms, for programs compiled with -m31, it could happen that GDB inadvertently cleared the inferior's 31-bit addressing mode bit and left the inferior running in 24-bit addressing mode. In particular this occurred with checkpoint.exp, when the "restore" command needed to create a new regcache copy: At the time when the PSWM register was copied over, the addressing mode bit was taken from the PSWA register, which was still zero since it had not been copied yet. And when the PSWA register was copied, the addressing mode was not updated again. The fix affects fill_gregset, where the bits "belonging" to each of the PSWA and PSWM registers are now carefully separated. The addressing mode bit is no longer touched when writing PSWM, and -- more importantly -- it *is* written when writing PSWA. gdb/ChangeLog: * s390-linux-nat.c (fill_gregset): Avoid relying on the PSWA register in the regcache when treating the PSWM register, and vice versa.
2015-05-08Skip watch_thread_num.exp on targets without access watchpointsAndreas Arnez2-1/+8
Since watch_thread_num.exp was changed to use access watchpoints, the test case fails on s390 and s390x, since those targets do not support access watchpoints. This patch skips the test case on such targets. gdb/testsuite/ChangeLog: * gdb.base/watch_thread_num.exp: Skip test on targets without access watchpoints.
2015-05-07Remove unused td_ta_map_id2thr codeGary Benson2-6/+6
linux-thread-db.c initializes td_ta_map_id2thr but never uses it. This commit removes this dead code. gdb/ChangeLog: * linux-thread-db.c (struct thread_db_info) <td_ta_map_id2thr_p>: Remove field. (try_thread_db_load_1): Remove initialization for the above.
2015-05-07Remove unused td_thr_validate codeGary Benson2-5/+6
linux-thread-db.c initializes td_thr_validate but never uses it. This commit removes this dead code. gdb/ChangeLog: * linux-thread-db.c (struct thread_db_info) <td_thr_validate_p>: Remove field. (try_thread_db_load_1): Remove initialization for the above.
2015-05-06compile: Support relocation to GNU-IFUNCsJan Kratochvil2-0/+9
Calling memcpy() could fail as memcpy() from libc is GNU-IFUNC. gdb/ChangeLog 2015-05-06 Jan Kratochvil <jan.kratochvil@redhat.com> * compile/compile-object-load.c (compile_object_load): Support mst_text_gnu_ifunc.
2015-05-06Code cleanup: compile: Constify some parametersJan Kratochvil3-7/+19
gdb/ChangeLog 2015-05-06 Jan Kratochvil <jan.kratochvil@redhat.com> * compile/compile.c (compile_to_object): Make the cmd_string parameter const. Use new variables for the const compatibility. (eval_compile_command): Make the cmd_string parameter const. * compile/compile.h (eval_compile_command): Make the cmd_string parameter const.
2015-05-06PR server/18081: gdbserver crashes when providing an unexisting binaryPedro Alves4-0/+75
$ ./gdbserver :1234 blah Process blah created; pid = 16471 Cannot exec blah: No such file or directory. Child exited with status 127 Killing process(es): 16471 ../../../../src/binutils-gdb/gdb/gdbserver/linux-low.c:920: A problem internal to GDBserver has been detected. kill_wait_lwp: Assertion `res > 0' failed. GDBserver shouldn't even be trying to kill that process. GDBserver kills or detaches from all processes on exit, and due to a missing mourn_inferior call, GDBserver tries to kill the process that it had already seen exit. Tested on x86_64 Fedora 20. New test included. I emulated what Windows outputs by hacking an error call in linux_create_inferior. gdb/gdbserver/ChangeLog: 2015-05-06 Pedro Alves <palves@redhat.com> PR server/18081 * server.c (start_inferior): If the process exits, mourn it. gdb/testsuite/ChangeLog: 2015-05-06 Pedro Alves <palves@redhat.com> PR server/18081 * gdb.server/non-existing-program.exp: New file.
2015-05-06Get rid of deprecated_init_ui_hookJoel Brobecker5-22/+11
This hook is no longer used, and can therefore be eliminated. gdb/ChangeLog: * defs.h (deprecated_init_ui_hook): Delete. Remove associated comment. * top.c (deprecated_init_ui_hook): Delete. (gdb_init): Remove handling of deprecated_init_ui_hook. * interps.c (clear_interpreter_hooks): Remove handling of deprecated_init_ui_hook. * main.c (captured_main): Update comment.
2015-05-06Make the "info dll" command available on all platform.Joel Brobecker6-11/+22
The "info dll", an alias of the "info sharedlibrary" command, is currently only defined in windows native versions. This patch makes it universally available by moving the alias declaration to solib.c, and adjusts the documentation accordingly. Making it universally available has two benefits: - Windows users moving to a Unix platforms are still able to use the same command for getting the list of shared libraries; - Unix to Windows cross debuggers now provide that command also. gdb/ChangeLog: * solib.c (_initialize_solib): Add "info dll" alias creation. * windows-nat.c (set_windows_aliases): Delete. (_initialize_windows_nat): Remove deprecated_init_ui_hook assignment. * NEWS: Add news entry about "info dll" now being available on all platforms. gdb/doc/ChangeLog: * gdb.texinfo (Files): Add "info dll" documentation. (Cygwin Native): Remove "info dll" documentation.
2015-05-05Further document ada-lang.c::value_assign_to_component & fix whitespaces.Joel Brobecker2-11/+22
This patch improves the documentation of ada-lang.c's value_assign_to_component to publish the fact that it also works with not_lval values. And touching this area of the code showed that there were a number of whitespace issues, as well as a formatting issue of the main comment (no leading '*' on each line). This patch fixes those while at it. No functional change, however. gdb/ChangeLog: * ada-lang.c (value_assign_to_component): Reformat and improve documentation. Remove all trailing spaces.
2015-05-05out of line functions nested inside inline functions.Joel Brobecker4-0/+27
This patch improves the handling of out-of-line functions nested inside functions that have been inlined. Consider for instance a situation where function Foo_O224_021 has a function Child1 declared in it, which itself has a function Child2 nested inside Child1. After compiling the program with optimization on, Child1 gets inlined, but not Child2. After inserting a breakpoint on Child2, and running the program until reaching that breakpoint, we get the following backtrace: % gdb foo_o224_021 (gdb) break foo_o224_021.child1.child2 (gdb) run [...] Breakpoint 1, foo_o224_021 () at foo_o224_021.adb:28 28 Child1; (gdb) bt #0 0x0000000000402400 in foo_o224_021 () at foo_o224_021.adb:28 #1 0x00000000004027a4 in foo_o224_021.child1 () at foo_o224_021.adb:23 #2 0x00000000004027a4 in foo_o224_021 () at foo_o224_021.adb:28 GDB reports the wrong function name for frame #0. We also get the same kind of error in the "Breakpoint 1, foo_o224_021 () [...]" message. In both cases, the function name should be foo_o224_021.child1.child2, and the parameters should be "s=...". What happens is that the inlined frame handling does not handle well the case where an inlined function is calling an out-of-line function which was declared inside the inlined function's scope. In particular, looking first at the inlined-frame sniffer when applying to frame #0: /* Calculate DEPTH, the number of inlined functions at this location. */ depth = 0; cur_block = frame_block; while (BLOCK_SUPERBLOCK (cur_block)) { if (block_inlined_p (cur_block)) depth++; cur_block = BLOCK_SUPERBLOCK (cur_block); } What happens is that cur_block starts as the block associated to child2, which is not inlined. We shoud be stopping here, but instead, we keep walking the superblock chain, which takes us all the way to Foo_O224_021's block, via Child2's block. And since Child1 was inlined, we end up with a depth count of 1, wrongly making GDB think that frame #0 is an inlined frame. Same kind of issue inside skip_inline_frames. The fix is to stop checking for inlined frames as soon as we see a block corresponding to a function which is not inlined. This is the behavior we now obtain: (gdb) run [...] Breakpoint 1, foo_o224_021.child1.child2 (s=...) at foo_o224_021.adb:9 9 function Child2 (S : String) return Boolean is (gdb) bt #0 0x0000000000402400 in foo_o224_021.child1.child2 (s=...) at foo_o224_021.adb:9 #1 0x00000000004027a4 in foo_o224_021.child1 () at foo_o224_021.adb:23 #2 0x00000000004027a4 in foo_o224_021 () at foo_o224_021.adb:28 gdb/ChangeLog: * inline-frame.c (inline_frame_sniffer, skip_inline_frames): Stop counting inlined frames as soon as an out-of-line function is found. gdb/testsuite/ChangeLog: * gdb.ada/out_of_line_in_inlined.exp: Add run and "bt" tests.
2015-05-05DWARF: cannot break on out-of-line function nested inside inlined function.Pierre-Marie de Rodat7-6/+159
Consider the following code, which defines a function, Child2, which is itself nested inside Child1: procedure Foo_O224_021 is O1 : constant Object_Type := Get_Str ("Foo"); procedure Child1 is O2 : constant Object_Type := Get_Str ("Foo"); function Child2 (S : String) return Boolean is -- STOP begin for C of S loop Do_Nothing (C); if C = 'o' then return True; end if; end loop; return False; end Child2; R : Boolean; begin R := Child2 ("Foo"); R := Child2 ("Bar"); R := Child2 ("Foobar"); end Child1; begin Child1; end Foo_O224_021; On x86_64-linux, when compiled at -O2, GDB is unable to insert a breakpoint on Child2: % gnatmake -g -O2 foo_o224_021 % gdb foo_o224_021 (gdb) b child2 Function "child2" not defined. (gdb) b foo_o224_021.child1.child2 Function "foo_o224_021.child1.child2" not defined. The problem is caused by the fact that GDB did not create a symbol for Child2, and this, in turn, is caused by the fact that the compiler decided to inline Child1, but not Child2. The DWARF debugging info first provides an abstract instance tree for Child1... <3><1b7b>: Abbrev Number: 29 (DW_TAG_subprogram) <1b7c> DW_AT_name : (indirect string, offset: 0x23f8): foo_o224_021__child1 <1b82> DW_AT_inline : 1 (inlined) <1b83> DW_AT_sibling : <0x1c01> ... where that subprogram is given the DW_AT_inline attribute. Inside that function there is a lexical block which has no PC range (corresponding to the fact that this is the abstract tree): <4><1b87>: Abbrev Number: 30 (DW_TAG_lexical_block) ... inside which our subprogram Child2 is described: <5><1b92>: Abbrev Number: 32 (DW_TAG_subprogram) <1b93> DW_AT_name : (indirect string, offset: 0x2452): foo_o224_021__child1__child2 <1b99> DW_AT_type : <0x1ab1> <1b9d> DW_AT_low_pc : 0x402300 <1ba5> DW_AT_high_pc : 0x57 [...] Then, later on, we get the concrete instance tree, starting at: <3><1c5e>: Abbrev Number: 41 (DW_TAG_inlined_subroutine) <1c5f> DW_AT_abstract_origin: <0x1b7b> <1c63> DW_AT_entry_pc : 0x4025fd <1c6b> DW_AT_ranges : 0x150 ... which refers to Child1. One of that inlined subroutine children is the concrete instance of the empty lexical block we saw above (in the abstract instance tree), which gives the actual address range for this inlined instance: <5><1c7a>: Abbrev Number: 43 (DW_TAG_lexical_block) <1c7b> DW_AT_abstract_origin: <0x1b87> <1c7f> DW_AT_ranges : 0x180 This is the DIE which provides the context inside which we can record Child2. But unfortunately, GDB does not take the abstract origin into account when handling lexical blocks, causing it to miss the fact that this block contains some symbols described in the abstract instance tree. This is the first half of this patch: modifying GDB to follow DW_AT_abstract_origin attributes for lexical blocks. But this not enough to fix the issue, as we're still unable to break on Child2 with just that change. The second issue can be traced to the way inherit_abstract_dies determines the list of DIEs to inherit from. For that, it iterates over all the DIEs in the concrete instance tree, and finds the list of DIEs from the abstract instance tree that are not referenced from the concrete instance tree. As it happens, there is one type of DIE in the concrete instance tree which does reference Child2's DIE, but in fact does otherwise define a concrete instance of the reference DIE; that's (where <0x1b92> is Child2's DIE): <6><1d3c>: Abbrev Number: 35 (DW_TAG_GNU_call_site) <1d3d> DW_AT_low_pc : 0x4026a4 <1d45> DW_AT_abstract_origin: <0x1b92> So, the second part of the patch is to modify inherit_abstract_dies to ignore DW_TAG_GNU_call_site DIEs when iterating over the concrete instance tree. This patch also includes a testcase which can be used to reproduce the issue. Unfortunately, for it to actually pass, a smal patch in GCC is also necessary to make sure that GCC provides lexical blocks' DW_AT_abstract_origin attributes from the concrete tree back to the abstract tree. We hope to be able to submit and integrate that patch in the GCC tree soon. Meanwhile, a setup_xfail has been added. gdb/ChangeLog: 2014-05-05 Pierre-Marie de Rodat <derodat@adacore.com> * dwarf2read.c (inherit_abstract_dies): Skip DW_TAG_GNU_call_site dies while inheriting children of an abstract DIE into a scope. (read_lexical_block_scope): Inherit abstract DIE's for lexical scopes. gdb/testsuite/ChangeLog: * gdb.ada/out_of_line_in_inlined: New testcase.
2015-05-05compare object sizes before comparing them with value_contents_eqJoel Brobecker3-3/+16
This is an issue which I noticed while working on trying to print an array of variant records. For instance, trying to print "A1", an array of elements whose size is variable, defined as follow (see gdb.ada/var_rec_arr testcase): subtype Small_Type is Integer range 0 .. 10; type Record_Type (I : Small_Type := 0) is record S : String (1 .. I); end record; function Ident (R : Record_Type) return Record_Type; type Array_Type is array (Integer range <>) of Record_Type; A1 : Array_Type := (1 => (I => 0, S => <>), 2 => (I => 1, S => "A"), 3 => (I => 2, S => "AB")); The debugger sometimes prints the array as follow: (gdb) print A1 $1 = ((i => 0, s => ""), (i => 0, s => ""), (i => 0, s => "")) The problem happens inside the part of the loop printing the array's elements, while trying to count the number of consecutive elements that have the same value (in order to replace them by the "<repeats nnn times>" message when the number exceeds a threshold). In particular, in ada-valprint.c::val_print_packed_array_elements: elttype = TYPE_TARGET_TYPE (type); eltlen = TYPE_LENGTH (check_typedef (elttype)); while (...) { if (!value_contents_eq (v0, value_embedded_offset (v0), v1, value_embedded_offset (v1), eltlen)) break; The value comparison is performed using value_contents_eq but makes the assumption that elttype is not dynamic, which is not always true. In particular, in the case above, elttype is dynamic and therefore its TYPE_LENGTH changes from element to element. As it happens in this case, the eltlen is zero, which causes the call to value_contents_eq to return true, and therefore GDB thinks all 3 elements of the array are equal. This patch fixes the issue by making sure that both v0 and v1, which are values whose type we expect to be resolved, have identical lengths. If not, then the two elements of the array cannot possibly have the same value and we do not even need to do the binary comparison. Unfortunately, this is still not enough to get GDB to print the correct value for our array, because the assumption that v0 and v1 have a type which has been resolved is actually not met. So, the second part of the patch modifies the function that constructed the values to make sure dynamic types do get resolved. gdb/ChangeLog: * ada-valprint.c (val_print_packed_array_elements): Delete variable "len". Add a type-length check when comparing two consecutive elements of the array. Use the element's actual length in call to value_contents_eq. * ada-lang.c (ada_value_primitive_packed_val): Always return a value whose type has been resolved.