- 07 Sep, 2017 2 commits
-
-
Joel Brobecker authored
gdb/ChangeLog: * version.in: Set GDB version number to 8.0.1. * PROBLEMS: Likewise.
-
GDB Administrator authored
-
- 06 Sep, 2017 1 commit
-
-
GDB Administrator authored
-
- 05 Sep, 2017 6 commits
-
-
Simon Marchi authored
Using follow-exec-mode "new" takes a different code path than "same", so it's interesting to test this path in combination with a change in architecture of the inferior. This test fails if you remove the previous patch. gdb/testsuite/ChangeLog: * gdb.multi/multi-arch-exec.exp: Test with different "follow-exec-mode" settings. (do_test): New procedure.
-
Simon Marchi authored
As mentioned in the previous patch, we should avoid doing register reads after a process does an exec and before we've updated that inferior's gdbarch. Otherwise, we may interpret the registers using the wrong architecture. When a process does an exec with "follow-exec-mode new", a new inferior is added by follow_exec. The gdbarch of that new inferior is at first set to some default value, probably specific to the gdb build (I get "i386" here), which may not be the right one. It is updated later by the call to target_find_description. Before that point, if we try to read the inferior's registers, we may not interpret them correctly. This has been exposed by a failure in gdb.base/foll-exec-mode.exp after the previous patch, with: Remote 'g' packet reply is too long (expected 312 bytes, got 816 bytes) The call to "add_thread" done just after adding the inferior is problematic, because it ends up reading the registers (because the ptid is re-used, we end up doing a switch_to_thread to it, which tries to update stop_pc). The registers returned by gdbserver are the x86-64 ones, while we try to interpret them using the "i386" gdbarch. Postponing the call to add_thread to until the target description/gdbarch has been updated seems to fix the issue. As to why this issue was uncovered by the previous patch: what I think happened before that patch is that since we were updating stop_pc before switching to the new inferior, we were filling the regcache associated to the ptid (this worked fine as long as the architectures of the previous and new process images were the same). The call to switch_to_thread then worked, because the register read hit the regcache. Now, it triggers a register read, while the gdbarch is not set correctly, leading to the "reply is too long" error. If this is right, it sounds wrong that we delete and re-add a thread with the same ptid, and are able to access the registers from the deleted thread. When we delete a thread, should we clear the regcache associated to that ptid, so that the new thread starts with a fresh/empty regcache? gdb/ChangeLog: * infrun.c (follow_exec): Call add_thread after target_find_description.
-
Simon Marchi authored
When an inferior execs and changes architecture (e.g. 64 bits to 32 bits), the gdbarch associated to the inferior is updated by the follow_exec call in handle_inferior_event_1. We should avoid doing any register read before that point, because the registers sent by the remote side will be those of the new architecture, but we would interpret them using the old architecture. We do just that by setting stop_pc during this window, which obviously requires reading the registers. This results in gdb.multi/multi-arch-exec.exp failing, GDB outputting the following error: Truncated register 50 in remote 'g' packet This patch fixes that by postponing the setting of stop_pc to after we've updated the inferior gdbarch. This bug was hiding another problem, and as such introduces some failures in gdb.base/foll-exec-mode.exp. The following patch takes care of that. gdb/ChangeLog: * infrun.c (handle_inferior_event_1): When exec'ing, read stop_pc after follow_exec.
-
Simon Marchi authored
... by adding the expected size, and the received size. I found this useful when debugging gdbarch/remote issues, since it gives a hint of what gdb expects and what the remote sent. gdb/ChangeLog: * remote.c (process_g_packet): Update error message.
-
John Baldwin authored
Previously this used the error function from GDB directly when linked against GDB instead of the error method in the host callbacks structure. This was exposed via a link error when GDB was converted to C++. The error function invokes the error callback similar to sim_io_error. Note that there are also error functions in sim/ppc/main.c and sim/ppc/misc.c. The ppc libsim.a expects each consumer to provide several symbols used by the library including "error". sim-calls.c provides these symbols when the library is linked into gdb. The dgen, igen, tmp-filter, tmp-ld-decode, tmp-ld-cache, and tmp-ld-insn programs use the functions from misc.c. psim uses the functions from main.c. sim/ppc/ChangeLog: PR sim/20863 * sim_calls.c (error): New function.
-
GDB Administrator authored
-
- 04 Sep, 2017 1 commit
-
-
GDB Administrator authored
-
- 03 Sep, 2017 1 commit
-
-
GDB Administrator authored
-
- 02 Sep, 2017 1 commit
-
-
GDB Administrator authored
-
- 01 Sep, 2017 2 commits
-
-
Jan Kratochvil authored
On <=RHEL6 hosts Fedora/RHEL GDB started to 'kill -STOP' all processes it detached. Even those not originally T-stopped. This is a Fedora-specific patch which is based on upstream GDB's PROC_STATE_STOPPED state. I believe (I did not verify) this patch did regress it: commit d617208b Author: Pedro Alves <palves@redhat.com> Date: Mon Jul 25 12:42:17 2016 +0100 linux-procfs: Introduce enum proc_state As originally there was strstr() but now there is strcmp() and so the missing trailing '\n' no longer matches. The Bug was found by Michal Kolar. Reproducibility: $ gdb -p $PID (gdb) quit $ ... Actual results: === RHEL6.9 x86_64 # scl enable devtoolset-7 bash RHEL6.9 x86_64 # which gdb /opt/rh/devtoolset-7/root/usr/bin/gdb RHEL6.9 x86_64 # ./testcase.sh 24737 pts/0 S+ 0:00 /bin/sleep 4 24737 pts/0 T+ 0:00 /bin/sleep 4 RHEL6.9 x86_64 # === Expected results: === RHEL6.9 x86_64 # which gdb /usr/bin/gdb RHEL6.9 x86_64 # ./testcase.sh 24708 pts/0 S+ 0:00 /bin/sleep 4 24708 pts/0 S+ 0:00 /bin/sleep 4 ./testcase.sh: line 20: kill: (24708) - No such process RHEL6.9 x86_64 # === gdb/ChangeLog 2017-09-01 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/22046 * nat/linux-procfs.c (parse_proc_status_state): Fix PROC_STATE_STOPPED detection.
-
GDB Administrator authored
-
- 31 Aug, 2017 1 commit
-
-
GDB Administrator authored
-
- 30 Aug, 2017 1 commit
-
-
GDB Administrator authored
-
- 29 Aug, 2017 1 commit
-
-
GDB Administrator authored
-
- 28 Aug, 2017 2 commits
-
-
Simon Marchi authored
Commit Command names: make them case sensitive 3d7b173c made command name lookup case sensitive. However, define_command, used when creating a user-defined command, converts the command name to lowercase, assuming that the command name lookup works in a case insensitive way. This causes user-defined commands with capital letters in their name to only be callable with a lowercase version: (gdb) define Foo Type commands for definition of "Foo". End with a line saying just "end". >print 1 >end (gdb) Foo Undefined command: "Foo". Try "help". (gdb) foo $1 = 1 This patch removes that conversion to lowercase, so that the user can call the command with the same name they provided. gdb/ChangeLog: * cli/cli-script.c (define_command): Don't convert command name to lower case. gdb/testsuite/ChangeLog: * gdb.base/commands.exp (user_defined_command_case_sensitivity): New proc, call it from toplevel.
-
GDB Administrator authored
-
- 27 Aug, 2017 1 commit
-
-
GDB Administrator authored
-
- 26 Aug, 2017 1 commit
-
-
GDB Administrator authored
-
- 25 Aug, 2017 1 commit
-
-
GDB Administrator authored
-
- 24 Aug, 2017 3 commits
-
-
Jan Kratochvil authored
-gdwarf-4: ptype logical type = const char [2] (gdb) PASS: gdb.base/constvars.exp: ptype logical -gdwarf-5: ptype logical type = const char [] (gdb) FAIL: gdb.base/constvars.exp: ptype logical <2><2fc>: Abbrev Number: 1 (DW_TAG_variable) <2fd> DW_AT_name : (indirect string, offset: 0x2eb): logical <301> DW_AT_decl_file : 1 1 DW_TAG_variable [no children] DW_AT_name DW_FORM_strp DW_AT_decl_file DW_FORM_implicit_const: 1 During symbol reading, invalid attribute class or form for 'DW_FORM_implicit_const' in '(null)'. gdb/ChangeLog 2017-08-24 Jan Kratochvil <jan.kratochvil@redhat.com> PR symtab/22003 * dwarf2read.c (dwarf2_const_value_attr, dump_die_shallow) (dwarf2_get_attr_constant_value, dwarf2_fetch_constant_bytes) (skip_form_bytes, attr_form_is_constant): Handle DW_FORM_implicit_const. -
Jan Kratochvil authored
GDB was now accessing as signatured_type memory allocated only by size of dwarf2_per_cu_data. gdb/ChangeLog 2017-08-24 Jan Kratochvil <jan.kratochvil@redhat.com> * dwarf2read.c (build_type_psymtabs_reader): New prototype. (process_psymtab_comp_unit): Accept IS_DEBUG_TYPES. (read_comp_units_from_section): New parameter abbrev_section, use read_and_check_comp_unit_head, allocate signatured_type if needed. (create_all_comp_units): Update read_comp_units_from_section caller.
-
GDB Administrator authored
-
- 23 Aug, 2017 1 commit
-
-
GDB Administrator authored
-
- 21 Aug, 2017 1 commit
-
-
GDB Administrator authored
-
- 20 Aug, 2017 1 commit
-
-
GDB Administrator authored
-
- 19 Aug, 2017 1 commit
-
-
GDB Administrator authored
-
- 18 Aug, 2017 1 commit
-
-
GDB Administrator authored
-
- 17 Aug, 2017 1 commit
-
-
GDB Administrator authored
-
- 16 Aug, 2017 1 commit
-
-
GDB Administrator authored
-
- 14 Aug, 2017 1 commit
-
-
GDB Administrator authored
-
- 13 Aug, 2017 1 commit
-
-
GDB Administrator authored
-
- 12 Aug, 2017 1 commit
-
-
GDB Administrator authored
-
- 11 Aug, 2017 2 commits
-
-
Maciej W. Rozycki authored
Fix a commit cd6c3b4f ("New gdbarch methods breakpoint_kind_from_pc and sw_breakpoint_from_kind") regression and restore the use of `->placed_address' rather than `->reqstd_address' as the location for a memory breakpoint to be inserted at. Previously `gdbarch_breakpoint_from_pc' was used that made that adjustment in `default_memory_insert_breakpoint' from the preinitialized value, however with the said commit that call is gone, so the passed `->placed_address' has to be used for the initialization. The regression manifests itself as the inability to debug any MIPS/Linux compressed ISA dynamic executable as GDB corrupts the dynamic loader with one of its implicit breakpoints, causing the program to crash, as seen for example with the `mips-linux-gnu' target, o32 ABI, MIPS16 code, and the gdb.base/advance.exp test case: (gdb) continue Continuing. Program received signal SIGBUS, Bus error. _dl_debug_initialize (ldbase=0, ns=0) at dl-debug.c:51 51 r = &_r_debug; (gdb) FAIL: gdb.base/advance.exp: Can't run to main gdb/ PR breakpoints/21886 * mem-break.c (default_memory_insert_breakpoint): Use `->placed_address' rather than `->reqstd_address' for the breakpoint location. (cherry picked from commit ba7b109b)
-
GDB Administrator authored
-
- 10 Aug, 2017 1 commit
-
-
GDB Administrator authored
-
- 09 Aug, 2017 2 commits
-
-
GDB Administrator authored