and though bugs are the bane of my existence, rest assured the wretched thing will get the best of care here

  1. 07 Sep, 2017 2 commits
  2. 06 Sep, 2017 1 commit
  3. 05 Sep, 2017 6 commits
    • Simon Marchi's avatar
      Test different follow-exec-mode settings in gdb.multi/multi-arch-exec.exp · e8311673
      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.
      e8311673
    • Simon Marchi's avatar
      Add thread after updating gdbarch when exec'ing · 42f0d821
      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.
      42f0d821
    • Simon Marchi's avatar
      Read stop_pc after updating the gdbarch when exec'ing · 61bffb81
      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.
      61bffb81
    • Simon Marchi's avatar
      Improve "'g' reply is is to long" error message · e72d662a
      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.
      e72d662a
    • John Baldwin's avatar
      Define an error function in the PPC simulator library. · 6854bcdf
      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.
      6854bcdf
    • GDB Administrator's avatar
      Automatic date update in version.in · c8e0d804
      GDB Administrator authored
      c8e0d804
  4. 04 Sep, 2017 1 commit
  5. 03 Sep, 2017 1 commit
  6. 02 Sep, 2017 1 commit
  7. 01 Sep, 2017 2 commits
    • Jan Kratochvil's avatar
      PR gdb/22046: Fix T-stopped detach regression on old Linux kernels · c247e38d
      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.
      c247e38d
    • GDB Administrator's avatar
      Automatic date update in version.in · e2763d8a
      GDB Administrator authored
      e2763d8a
  8. 31 Aug, 2017 1 commit
  9. 30 Aug, 2017 1 commit
  10. 29 Aug, 2017 1 commit
  11. 28 Aug, 2017 2 commits
    • Simon Marchi's avatar
      define_command: Don't convert command name to lower case · 95eeca3b
      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.
      95eeca3b
    • GDB Administrator's avatar
      Automatic date update in version.in · ca3c097c
      GDB Administrator authored
      ca3c097c
  12. 27 Aug, 2017 1 commit
  13. 26 Aug, 2017 1 commit
  14. 25 Aug, 2017 1 commit
  15. 24 Aug, 2017 3 commits
    • Jan Kratochvil's avatar
      DWARF-5 Fix DW_FORM_implicit_const · f74f69f4
      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.
      f74f69f4
    • Jan Kratochvil's avatar
      DWARF-5: Fix -fdebug-types-section · 06f84c95
      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.
      06f84c95
    • GDB Administrator's avatar
      Automatic date update in version.in · 75b46e0c
      GDB Administrator authored
      75b46e0c
  16. 23 Aug, 2017 1 commit
  17. 21 Aug, 2017 1 commit
  18. 20 Aug, 2017 1 commit
  19. 19 Aug, 2017 1 commit
  20. 18 Aug, 2017 1 commit
  21. 17 Aug, 2017 1 commit
  22. 16 Aug, 2017 1 commit
  23. 14 Aug, 2017 1 commit
  24. 13 Aug, 2017 1 commit
  25. 12 Aug, 2017 1 commit
  26. 11 Aug, 2017 2 commits
    • Maciej W. Rozycki's avatar
      PR breakpoints/21886: mem-break: Fix breakpoint insertion location · b3e687f4
      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)
      b3e687f4
    • GDB Administrator's avatar
      Automatic date update in version.in · 974a833e
      GDB Administrator authored
      974a833e
  27. 10 Aug, 2017 1 commit
  28. 09 Aug, 2017 2 commits