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

  1. 24 Oct, 2020 2 commits
  2. 23 Oct, 2020 1 commit
  3. 22 Oct, 2020 4 commits
    • Hannes Domani's avatar
      Don't create _Complex type name if there is no target type name · 7565d82a
      Hannes Domani authored
      This causes gdb to crash in strlen.
      
      Happens if init_complex_type is called for a type created by
      dbx_init_float_type in stabsread.c.
      
      gdb/ChangeLog:
      
      2020-10-22  Hannes Domani  <ssbssa@yahoo.de>
      
      	* gdbtypes.c (init_complex_type): Check target type name.
      7565d82a
    • Andrew Burgess's avatar
      opcodes/csky: return the default disassembler when there is no bfd · a9e3b919
      Andrew Burgess authored
      The disassembler function should return a valid disassembler function
      even when there is no BFD present.  This is implied (I believe) by the
      comment in dis-asm.h which says the BFD may be NULL.  Further, it
      makes sense when considering that the disassembler is used in GDB, and
      GDB may connect to a target and perform debugging even without a BFD
      being supplied.
      
      This commit makes the csky_get_disassembler function return the
      default disassembler configuration when no bfd is supplied, this is
      the same default configuration as is used when a BFD is supplied, but
      the BFD has no attributes section.
      
      Before the change configuring GDB with --enable-targets=all and
      running the tests gdb.base/all-architectures-2.exp results in many
      errors, but after this change there are no failures.
      
      opcodes/ChangeLog:
      
      	* csky-dis.c (csky_get_disassembler): Don't return NULL when there
      	is no BFD.
      a9e3b919
    • Simon Marchi's avatar
      gdb/dwarf: fix reading subprogram with DW_AT_specification (PR gdb/26693) · 4c02be11
      Simon Marchi authored
      Fix a regression introduced by commit 7188ed02 ("Replace
      dwarf2_per_cu_data::cu backlink with per-objfile map").
      
      This patch targets both master and gdb-10-branch, since this is a
      regression from GDB 9.
      
      Analysis
      --------
      
      The DWARF generated by the included test case looks like:
      
          0x0000000b: DW_TAG_compile_unit
                        DW_AT_language [DW_FORM_sdata]    (4)
      
          0x0000000d:   DW_TAG_base_type
                          DW_AT_name [DW_FORM_string]     ("int")
                          DW_AT_byte_size [DW_FORM_data1] (0x04)
                          DW_AT_encoding [DW_FORM_sdata]  (5)
      
          0x00000014:   DW_TAG_subprogram
                          DW_AT_name [DW_FORM_string]     ("apply")
      
          0x0000001b:   DW_TAG_subprogram
                          DW_AT_specification [DW_FORM_ref4]      (0x00000014 "apply")
                          DW_AT_low_pc [DW_FORM_addr]     (0x0000000000001234)
                          DW_AT_high_pc [DW_FORM_data8]   (0x0000000000000020)
      
          0x00000030:     DW_TAG_template_type_parameter
                            DW_AT_name [DW_FORM_string]   ("T")
                            DW_AT_type [DW_FORM_ref4]     (0x0000000d "int")
      
          0x00000037:     NULL
      
          0x00000038:   NULL
      
      Simply loading the file in GDB makes it crash:
      
          $ ./gdb -nx --data-directory=data-directory testsuite/outputs/gdb.dwarf2/pr26693/pr26693
          [1]    15188 abort (core dumped)  ./gdb -nx --data-directory=data-directory
      
      The crash happens here, where htab (a dwarf2_cu::die_hash field) is
      unexpectedly NULL while generating partial symbols:
      
          #0  0x000055555fa28188 in htab_find_with_hash (htab=0x0, element=0x7fffffffbfa0, hash=27) at /home/simark/src/binutils-gdb/libiberty/hashtab.c:591
          #1  0x000055555cb4eb2e in follow_die_offset (sect_off=(unknown: 27), offset_in_dwz=0, ref_cu=0x7fffffffc110) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22951
          #2  0x000055555cb4edfb in follow_die_ref (src_die=0x0, attr=0x7fffffffc130, ref_cu=0x7fffffffc110) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22968
          #3  0x000055555caa48c5 in partial_die_full_name (pdi=0x621000157e70, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8441
          #4  0x000055555caa4d79 in add_partial_symbol (pdi=0x621000157e70, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8469
          #5  0x000055555caa7d8c in add_partial_subprogram (pdi=0x621000157e70, lowpc=0x7fffffffc5c0, highpc=0x7fffffffc5e0, set_addrmap=1, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8737
          #6  0x000055555caa265c in scan_partial_symbols (first_die=0x621000157e00, lowpc=0x7fffffffc5c0, highpc=0x7fffffffc5e0, set_addrmap=1, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8230
          #7  0x000055555ca98e3f in process_psymtab_comp_unit_reader (reader=0x7fffffffc6b0, info_ptr=0x60600009650d "\003int", comp_unit_die=0x621000157d10, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7614
          #8  0x000055555ca9aa2c in process_psymtab_comp_unit (this_cu=0x621000155510, per_objfile=0x613000009f80, want_partial_unit=false, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7712
          #9  0x000055555caa051a in dwarf2_build_psymtabs_hard (per_objfile=0x613000009f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8073
      
      The special thing about this DWARF is that the subprogram at 0x1b is a
      template specialization described with DW_AT_specification, and has no
      DW_AT_name in itself.  To compute the name of this subprogram,
      partial_die_full_name needs to load the full DIE for this partial DIE.
      The name is generated from the templated function name and the actual
      tempalate parameter values of the specialization.
      
      To load the full DIE, partial_die_full_name creates a dummy DWARF
      attribute of form DW_FORM_ref_addr that points to our subprogram's DIE,
      and calls follow_die_ref on it.  This eventually causes
      load_full_comp_unit to be called for the exact same CU we are currently
      making partial symbols for:
      
          #0  load_full_comp_unit (this_cu=0x621000155510, per_objfile=0x613000009f80, skip_partial=false, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:9238
          #1  0x000055555cb4e943 in follow_die_offset (sect_off=(unknown: 27), offset_in_dwz=0, ref_cu=0x7fffffffc110) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22942
          #2  0x000055555cb4edfb in follow_die_ref (src_die=0x0, attr=0x7fffffffc130, ref_cu=0x7fffffffc110) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22968
          #3  0x000055555caa48c5 in partial_die_full_name (pdi=0x621000157e70, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8441
          #4  0x000055555caa4d79 in add_partial_symbol (pdi=0x621000157e70, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8469
          #5  0x000055555caa7d8c in add_partial_subprogram (pdi=0x621000157e70, lowpc=0x7fffffffc5c0, highpc=0x7fffffffc5e0, set_addrmap=1, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8737
          #6  0x000055555caa265c in scan_partial_symbols (first_die=0x621000157e00, lowpc=0x7fffffffc5c0, highpc=0x7fffffffc5e0, set_addrmap=1, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8230
          #7  0x000055555ca98e3f in process_psymtab_comp_unit_reader (reader=0x7fffffffc6b0, info_ptr=0x60600009650d "\003int", comp_unit_die=0x621000157d10, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7614
          #8  0x000055555ca9aa2c in process_psymtab_comp_unit (this_cu=0x621000155510, per_objfile=0x613000009f80, want_partial_unit=false, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7712
          #9  0x000055555caa051a in dwarf2_build_psymtabs_hard (per_objfile=0x613000009f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8073
      
      load_full_comp_unit creates a cutu_reader for the CU.  Since a dwarf2_cu
      object already exists for the CU, load_full_comp_unit is expected to
      find it and pass it to cutu_reader, so that cutu_reader doesn't create
      a new dwarf2_cu for the CU.
      
      And this is the difference between before and after the regression.
      Before commit 7188ed02, the dwarf2_per_cu_data -> dwarf2_cu link was
      a simple pointer in dwarf2_per_cu_data.  This pointer was set up when
      starting the read the partial symbols.  So it was already available at
      that point where load_full_comp_unit gets called.  Post-7188ed02,
      this link is per-objfile, kept in the dwarf2_per_objfile::m_dwarf2_cus
      hash map.  The entry is only put in the hash map once the partial
      symbols have been successfully read, when cutu_reader::keep is called.
      Therefore, it is _not_ set at the point load_full_comp_unit is called.
      
      As a consequence, a new dwarf2_cu object gets created and initialized by
      load_full_comp_unit (including initializing that dwarf2_cu::die_hash
      field).  Meanwhile, the dwarf2_cu object created and used by the callers
      up the stack does not get initialized for full symbol reading, and the
      dwarf2_cu::die_hash field stays unexpectedly NULL.
      
      Solution
      --------
      
      Since the caller of load_full_comp_unit knows about the existing
      dwarf2_cu object for the CU we are reading (the one load_full_comp_unit
      is expected to find), we can simply make it pass it down, instead of
      having load_full_comp_unit look up the per-objfile map.
      
      load_full_comp_unit therefore gets a new `existing_cu` parameter.  All
      other callers get updated to pass `per_objfile->get_cu (per_cu)`, so the
      behavior shouldn't change for them, compared to the current HEAD.
      
      A test is added, which is the bare minimum to reproduce the issue.
      
      Notes
      -----
      
      The original problem was reproduced by downloading
      
          https://github.com/oneapi-src/oneTBB/releases/download/v2020.3/tbb-2020.3-lin.tgz
      
      and loading libtbb.so in GDB.  This code was compiled with the Intel
      C/C++ compiler.  I was not able to reproduce the issue using GCC, I
      think because GCC puts a DW_AT_name in the specialized subprogram, so
      there's no need for partial_die_full_name to load the full DIE of the
      subprogram, and the faulty code doesn't execute.
      
      gdb/ChangeLog:
      
      	PR gdb/26693
      	* dwarf2/read.c (load_full_comp_unit): Add existing_cu
      	parameter.
      	(load_cu): Pass existing CU.
      	(process_imported_unit_die): Likewise.
      	(follow_die_offset): Likewise.
      
      gdb/testsuite/ChangeLog:
      
      	PR gdb/26693
      	* gdb.dwarf2/template-specification-full-name.exp: New test.
      
      Change-Id: I57c8042f96c45f15797a3848e4d384181c56bb44
      4c02be11
    • GDB Administrator's avatar
      Automatic date update in version.in · 9a312e49
      GDB Administrator authored
      9a312e49
  4. 21 Oct, 2020 1 commit
  5. 20 Oct, 2020 1 commit
  6. 19 Oct, 2020 2 commits
    • Mihails Strasuns's avatar
      gdb: get jiter objfile from a bound minsym · a606acc8
      Mihails Strasuns authored
      This fixes a regression introduced by the following commit:
      
      fe053b9e gdb/jit: pass the jiter objfile as an argument to jit_event_handler
      
      In the refactoring `handle_jit_event` function was changed to pass a matching
      objfile pointer to the `jit_event_handler` explicitly, rather using internal
      storage:
      
      ```
      --- a/gdb/breakpoint.c
      +++ b/gdb/breakpoint.c
      @@ -5448,8 +5448,9 @@ handle_jit_event (void)
      
         frame = get_current_frame ();
         gdbarch = get_frame_arch (frame);
      +  objfile *jiter = symbol_objfile (get_frame_function (frame));
      
      -  jit_event_handler (gdbarch);
      +  jit_event_handler (gdbarch, jiter);
      ```
      
      This was needed to add support for multiple jiters.  However it has also
      introduced a regression, because `get_frame_function (frame)` here may
      return `nullptr`, resulting in a crash.
      
      A more resilient way would be to use an approach mirroring
      `jit_breakpoint_re_set` - to find a minimal symbol matching the
      breakpoint location and use its object file.  We know that this
      breakpoint event comes from a breakpoint set by `jit_breakpoint_re_set`,
      thus using the reverse approach should be reliable enough.
      
      gdb/Changelog:
      2020-10-14  Mihails Strasuns  <mihails.strasuns@intel.com>
      
      	* breakpoint.c (handle_jit_event): Add an argument, change how
      	`jit_event_handler` is called.
      a606acc8
    • GDB Administrator's avatar
      Automatic date update in version.in · aa873d83
      GDB Administrator authored
      aa873d83
  7. 18 Oct, 2020 1 commit
  8. 17 Oct, 2020 1 commit
  9. 16 Oct, 2020 1 commit
  10. 15 Oct, 2020 1 commit
  11. 14 Oct, 2020 1 commit
  12. 13 Oct, 2020 2 commits
    • Simon Marchi's avatar
      gdb: don't pass TARGET_WNOHANG to targets that can't async (PR 26642) · f9052d5c
      Simon Marchi authored
      Debugging with "maintenance set target-async off" on Linux has been
      broken since 5b6d1e4f ("Multi-target support").
      
      The issue is easy to reproduce:
      
          $ ./gdb -q --data-directory=data-directory -nx ./test
          Reading symbols from ./test...
          (gdb) maintenance set target-async off
          (gdb) start
          Temporary breakpoint 1 at 0x1151: file test.c, line 5.
          Starting program: /home/simark/build/binutils-gdb/gdb/test
      
      ... and it hangs there.
      
      The difference between pre-5b6d1e4f and 5b6d1e4f is that
      fetch_inferior_event now calls target_wait with TARGET_WNOHANG for
      non-async-capable targets, whereas it didn't before.
      
      For non-async-capable targets, this is how it's expected to work when
      resuming execution:
      
      1. we call resume
      2. the infrun async handler is marked in prepare_to_wait, to immediately
         wake up the event loop when we get back to it
      3. fetch_inferior_event calls the target's wait method without
         TARGET_WNOHANG, effectively blocking until the target has something
         to report
      
      However, since we call the target's wait method with TARGET_WNOHANG,
      this happens:
      
      1. we call resume
      2. the infrun async handler is marked in prepare_to_wait, to immediately
         wake up the event loop when we get back to it
      3. fetch_inferior_event calls the target's wait method with
         TARGET_WNOHANG, the target has nothing to report yet
      4. we go back to blocking on the event loop
      5. SIGCHLD finally arrives, but the event loop is not woken up, because
         we are not in async mode.  Normally, we should have been stuck in
         waitpid the SIGCHLD would have unblocked us.
      
      We end up in this situation because these two necessary conditions are
      met:
      
      1. GDB uses the TARGET_WNOHANG option with a target that can't do async.
         I don't think this makes sense.  I mean, it's technically possible,
         the doc for TARGET_WNOHANG is:
      
        /* Return immediately if there's no event already queued.  If this
           options is not requested, target_wait blocks waiting for an
           event.  */
        TARGET_WNOHANG = 1,
      
         ... which isn't in itself necessarily incompatible with synchronous
         targets.  It could be possible for a target to support non-blocking
         polls, while not having a way to asynchronously wake up the event
         loop, which is also necessary to support async.  But as of today,
         we don't expect GDB and sync targets to work this way.
      
      2. The linux-nat target, even in the mode where it emulates a
         synchronous target (with "maintenance set target-async off") respects
         TARGET_WNOHANG.  Other non-async targets, such as windows_nat_target,
         simply don't check / support TARGET_WNOHANG, so their wait method is
         always blocking.
      
      Fix the first issue by avoiding using TARGET_WNOHANG on non-async
      targets, in do_target_wait_1.  Add an assert in target_wait to verify it
      doesn't happen.
      
      The new test gdb.base/maint-target-async-off.exp is a simple test that
      just tries running to main and then to the end of the program, with
      "maintenance set target-async off".
      
      gdb/ChangeLog:
      
      	PR gdb/26642
      	* infrun.c (do_target_wait_1): Clear TARGET_WNOHANG if the
      	target can't do async.
      	* target.c (target_wait): Assert that we don't pass
      	TARGET_WNOHANG to a target that can't async.
      
      gdb/testsuite/ChangeLog:
      
      	PR gdb/26642
      	* gdb.base/maint-target-async-off.c: New test.
      	* gdb.base/maint-target-async-off.exp: New test.
      
      Change-Id: I69ad3a14598863d21338a8c4e78700a58ce7ad86
      f9052d5c
    • GDB Administrator's avatar
      Automatic date update in version.in · 0241ddc7
      GDB Administrator authored
      0241ddc7
  13. 12 Oct, 2020 1 commit
  14. 11 Oct, 2020 1 commit
  15. 10 Oct, 2020 1 commit
  16. 09 Oct, 2020 2 commits
    • Joel Brobecker's avatar
      gnulib: fix stat/fstat build errors on old Windows version or using old MinGW · dc37fea7
      Joel Brobecker authored
      This commit imports two commits from gnulib's master branch fixing
      a build error when building on a version of Windows that's older
      than Vista, or when using an mingw's MinGW.
      
      gnulib/ChangeLog:
      
      	GDB PR build/26607
      	* patches/0002-stat-fstat-windows-older-vista: New patch.
      	* patches/0003-stat-fstat-windows-old-mingw: New patch.
      	* update-gnulib.sh: Update to use the two new patches above.
      	* import/m4/fstat.m4: Update after applying patches above.
      	* import/m4/stat.m4: Ditto.
      	* import/stat-w32.c: Ditto.
      	* config.in: Regenerate.
      	* configure: Regenerate.
      dc37fea7
    • GDB Administrator's avatar
      Automatic date update in version.in · 114f9fd9
      GDB Administrator authored
      114f9fd9
  17. 08 Oct, 2020 2 commits
  18. 07 Oct, 2020 5 commits
    • Anton Kolesov's avatar
      arc: Add support for Linux coredump files · 460fd13b
      Anton Kolesov authored
      With the implemenations in this patch, ARC gdb can handle
      coredump related matters.  The binutils counter part of
      this patch has already been pushed [1].
      
      v2 [2]:
      - arc_linux_collect_gregset: Use "reg <= ARC_LAST_REGNUM" instead of
        "reg < ARC_LAST_REGNUM" for the condition check of the for-loop.
      - arc-linux-tdep.c: Use "ARC_LAST_REGNUM < ARRAY_SIZE (...)" instead of
        "ARC_LAST_REGNUM <= ARRAY_SIZE (...)" for the "asserts".
      - Use "buf + arc_linux_core_reg_offsets[ARC_ERET_REGNUM]" instead of
        "buf + REG_OFF (6)".
      - Fix a few typos/indentation.
      
      v3 [3]:
      - Use gdb_assert_not_reached(text) instead of gdb_assert (!text).
      - Remove unnecessary braces in the for loop.
      
      [1] arc: Add support for ARC HS extra registers in core files
      https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=2745674244d6aecddcf636475034bdb9c0a6b4a0
      
      [2] First remarks
      https://sourceware.org/pipermail/gdb-patches/2020-September/171912.html
      
      [3] Second remarks
      https://sourceware.org/pipermail/gdb-patches/2020-October/172302.html
      
      gdb/ChangeLog:
      
      	* arc-linux-tdep.h: New file.
      	* arc-linux-tdep.c (arc_linux_core_reg_offsets,
      	arc_linux_supply_gregset, arc_linux_supply_v2_regset,
      	arc_linux_collect_gregset, arc_linux_collect_v2_regset,
      	arc_linux_gregset, arc_linux_v2_regset,
      	arc_linux_iterate_over_regset_sections,
      	arc_linux_core_read_description): Implement.
      	(arc_linux_init_osabi): Set iterate_over_regset_sections.
      	* arc-tdep.h (ARC_OFFSET_NO_REGISTER): Declare.
              (arc_gdbarch_features_create): Add.
      	* arc-tdep.c (arc_gdbarch_features_create): Not static anymore.
      460fd13b
    • Shahab Vahedi's avatar
      gdb/gdbserver: Add the missing ChangeLog entries · 94265abc
      Shahab Vahedi authored
      I forgot to add the ChangeLog entries for these 2 patches:
      
      b13599da gdbserver: Add GNU/Linux support for ARC
      e26d3e9b arc: Rename "arc_gdbarch_features" struct
      94265abc
    • Anton Kolesov's avatar
      gdbserver: Add GNU/Linux support for ARC · b13599da
      Anton Kolesov authored
      This gdbserver implementation supports ARC ABI v3 and v4 (older ARC ABI
      versions are not supported by other modern GNU tools or Linux itself).
      Gdbserver supports inspection of ARC HS registers R30, R58 and R59 - feature
      that has been added to Linux 4.12.  Whether gdbserver build will actually
      support this feature depends on the version of Linux headers used to build
      the server.
      
      v2 [1]:
      - Use "this->read_memory ()" instead of "the_target->read_memory ()".
      - Remove the unnecessary "arch-arc.o:" target from the "Makefile.in".
      - Got rid of "ntohs()" function and added lots of comments about
        endianness.
      - Clarify why "pc" value is read from and saved to different fields
        in user regs struct.
      - In function "is_reg_name_available_p()", use a range-based iterator
        to loop over the registers.
      - Removed mentioning of issue number that was not related to sourceware.
      - A few typo's fixed.
      
      [1] Remarks
      https://sourceware.org/pipermail/gdb-patches/2020-September/171911.html
      https://sourceware.org/pipermail/gdb-patches/2020-September/171919.html
      
      gdbserver/ChangeLog:
      
      	* configure.srv: Support ARC architecture.
      	* Makefile.in: Add linux-arc-low.cc and arch/arc.o.
      	* linux-arc-low.cc: New file.
      b13599da
    • Shahab Vahedi's avatar
      arc: Rename "arc_gdbarch_features" struct · e26d3e9b
      Shahab Vahedi authored
      "arc_gdbarch_features" is a data structure containing information
      about the ARC architecture: ISA version, register size, etc.
      This name is misleading, because although it carries the phrase
      "gdbarch", it has nothing to do with the type/interface in GDB.
      Traditionaly, "gdbarch" structures are only used for that purpose.
      To rectify this, this patch changes the name to "arc_arch_features".
      
      gdb/ChangeLog:
      
      	* arch/arc.h: Rename "arc_gdbarch_features" to
      	"arc_arch_features".
      	* arc-tdep.h: Likewise.
      	* arc-tdep.c: Likewise.
      e26d3e9b
    • GDB Administrator's avatar
      Automatic date update in version.in · 8f97e9b7
      GDB Administrator authored
      8f97e9b7
  19. 06 Oct, 2020 1 commit
  20. 05 Oct, 2020 1 commit
  21. 04 Oct, 2020 1 commit
  22. 03 Oct, 2020 1 commit
  23. 02 Oct, 2020 1 commit
  24. 01 Oct, 2020 1 commit
  25. 30 Sep, 2020 1 commit
  26. 29 Sep, 2020 1 commit
  27. 28 Sep, 2020 2 commits
    • Gareth Rees's avatar
      gdb: Fix from_tty argument to gdb.execute in Python. · f6c03ee4
      Gareth Rees authored
      Prior to commit 56bcdbea, the from_tty keyword argument to the
      Python function gdb.execute controlled whether the command took input
      from the terminal. When from_tty=True, "starti" and similar commands
      prompted the user:
      
          (gdb) python gdb.execute("starti", from_tty=True)
          The program being debugged has been started already.
          Start it from the beginning? (y or n) y
          Starting program: /bin/true
      
          Program stopped.
      
      When from_tty=False, these commands did not prompt the user, and "yes"
      was assumed:
      
          (gdb) python gdb.execute("starti", from_tty=False)
      
          Program stopped.
      
      However, after commit 56bcdbea, the from_tty keyword argument no
      longer had this effect. For example, as of commit 7ade7fba:
      
          (gdb) python gdb.execute("starti", from_tty=True)
          The program being debugged has been started already.
          Start it from the beginning? (y or n) [answered Y; input not from terminal]
          Starting program: /bin/true
      
          Program stopped.
      
      Note the "[answered Y; input not from terminal]" in the output even
      though from_tty=True was requested.
      
      Looking at commit 56bcdbea, it seems that the behaviour of the
      from_tty argument was changed accidentally. The commit message said:
      
          Let gdb.execute handle multi-line commands
      
          This changes the Python API so that gdb.execute can now handle
          multi-line commands, like "commands" or "define".
      
      and there was no mention of changing the effect of the from_tty
      argument. It looks as though the code for setting the instream to
      nullptr was accidentally moved from execute_user_command() to
      execute_control_commands() along with the other scoped restores.
      
      Accordingly, the simplest way to fix this is to partially reverse
      commit 56bcdbea by moving the code for setting the instream to
      nullptr back to execute_user_command() where it was to begin with.
      
      Additionally, add a test case to reduce the risk of similar breakage
      in future.
      
      gdb/ChangeLog:
      
      	PR python/26586
      	* cli/cli-script.c (execute_control_commands): don't set
      	instream to nullptr here as this breaks the from_tty argument
      	to gdb.execute in Python.
      	(execute_user_command): set instream to nullptr here instead.
      
      gdb/testsuite/ChangeLog:
      
      	PR python/26586
      	* gdb.python/python.exp: add test cases for the from_tty
      	argument to gdb.execute.
      
      (cherry picked from commit 8f9929bb)
      f6c03ee4
    • GDB Administrator's avatar
      Automatic date update in version.in · 5cb6abf2
      GDB Administrator authored
      5cb6abf2