arc: Write correct "eret" value during register collection

In collect_register() function of arc-linux-tdep.c, the "eret"
(exception return) register value was not being reported correctly.
This patch fixes that.

Background:
When asked for the "pc" value, we have to update the "eret" register
with GDB's STOP_PC.  The "eret" instructs the kernel code where to
jump back when an instruction has stopped due to a breakpoint.  This
is how collect_register() was doing so:

--------------8<--------------
  if (regnum == gdbarch_pc_regnum (gdbarch))
    regnum = ARC_ERET_REGNUM;
  regcache->raw_collect (regnum, buf + arc_linux_core_reg_offsets[regnum]);
-------------->8--------------

Root cause:
Although this is using the correct offset (ERET register's), it is also
changing the REGNUM itself.  Therefore, raw_collect (regnum, ...) is
not reading from "pc" anymore.

v2:
- Fix a copy/paste issue as rightfully addressed by Tom [1].

[1]
https://sourceware.org/pipermail/gdb-patches/2020-November/173208.html

gdb/ChangeLog:

* arc-linux-tdep.c (collect_register): Populate "eret" by
"pc" value from the regcache when asked for "pc" value.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Fix Value.format_string docu for static members argument

The argument is called static_members, not static_fields.

gdb/doc/ChangeLog:

2020-11-29  Hannes Domani  <ssbssa@yahoo.de>

PR python/26974
* python.texi: Fix docu for static members argument.

Don't delete the locator win info

The locator win info is special because it is static, all the others are
created dynamically.

gdb/ChangeLog:

2020-11-29  Hannes Domani  <ssbssa@yahoo.de>

PR tui/26973
* tui/tui-layout.c (tui_apply_current_layout): Don't delete the
static locator win info.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb: better static python detection in configure machinery

In python 3, itertools is a builtin module, so whether or not the
python you link against is a shared or a static one, importing it
works.

Change the import test to use ctypes which is a dynamic module in both
python 2 and 3.

gdb/ChangeLog:

PR python/26832
* configure: Regenerate.
* configure.ac: Check for python modules ctypes instead of
itertools.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Bump GDB version number to 10.1.90.DATE-git.

gdb/ChangeLog:

* version.in: Set GDB version number to 10.1.90.DATE-git.

gdb/testsuite/ChangeLog:

* gdb.base/default.exp: Change $_gdb_minor to 2.

Document the GDB 10.1 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 10.1 released.

Set GDB version number to 10.1.

gdb/ChangeLog:

* version.in: Set GDB version number to 10.1.

Automatic date update in version.in

Automatic date update in version.in

Don't create _Complex type name if there is no target type name

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.

opcodes/csky: return the default disassembler when there is no bfd

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.

gdb/dwarf: fix reading subprogram with DW_AT_specification (PR gdb/26693)

Fix a regression introduced by commit 7188ed02d2a7 ("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 7188ed02d2a7, 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-7188ed02d2a7,
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

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb: get jiter objfile from a bound minsym

This fixes a regression introduced by the following commit:

fe053b9e853 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.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb: don't pass TARGET_WNOHANG to targets that can't async (PR 26642)

Debugging with "maintenance set target-async off" on Linux has been
broken since 5b6d1e4fa4f ("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-5b6d1e4fa4f and 5b6d1e4fa4f 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

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gnulib: fix stat/fstat build errors on old Windows version or using old MinGW

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.

Automatic date update in version.in

Update GDB NEWS with ARC support in GDBserver

gdb/ChangeLog:

* NEWS: Mention ARC support in GDBserver.

Automatic date update in version.in

arc: Add support for Linux coredump files

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.

gdb/gdbserver: Add the missing ChangeLog entries

I forgot to add the ChangeLog entries for these 2 patches:

b13599da1ae gdbserver: Add GNU/Linux support for ARC
e26d3e9b761 arc: Rename "arc_gdbarch_features" struct

gdbserver: Add GNU/Linux support for ARC

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.

arc: Rename "arc_gdbarch_features" struct

"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.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb: Fix from_tty argument to gdb.execute in Python.

Prior to commit 56bcdbea2b, 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 56bcdbea2b, the from_tty keyword argument no
longer had this effect. For example, as of commit 7ade7fba75:

    (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 56bcdbea2b, 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 56bcdbea2b 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 8f9929bb97dc0f0fdf60269ac8c9a7d50746646f)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb/breakpoint: make a copy of the "commands" command's argument

When GDB reads commands from the input, its internal buffer is re-used
for each line.  This is usually just fine because commands are
executed in order; by the time we read the next line, we are already
done with the current line.  However, a problematic case is breakpoint
commands that are input from a script.  The header (e.g. commands 1 2)
is overwritten with the next line before the breakpoint numbers are
processed completely.

For example, suppose we have the following script:

  break main
  break main
  commands 1 2
    print 100123
  end

and source this script:

  (gdb) source script.gdb
  Breakpoint 1 at 0x1245: file main.cpp, line 27.
  Breakpoint 2 at 0x1245: file main.cpp, line 27.
  No breakpoint number 123.

Note the "No breakpoint number 123." error message.  This happens
because GDB first reads "commands 1 2" into its internal buffer

  buffer -> "commands 1 2"

and then starts parsing the breakpoint numbers.  After parsing the first
token, the "next token" pointer is as below:

  buffer -> "commands 1 2"
  next-token -----------^

So, if we continue parsing, we would tokenize "2" correctly.  However,
before parsing the next number, GDB reads the commands to attach them
to breakpoint 1.  Reading the commands causes the buffer to be
overwritten:

  buffer -> "  print 100123"
  next-token -----------^

So, the next time we parse the breakpoint number, we read "123".

To fix, simply create a copy of the arguments of the header.

gdb/ChangeLog:
2020-09-25  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

* breakpoint.c (commands_command_1): Make a copy of the 'arg'
argument.

gdb/testsuite/ChangeLog:
2020-09-25  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

* gdb.base/bp-cmds-sourced-script.c: New file.
* gdb.base/bp-cmds-sourced-script.exp: New test.
* gdb.base/bp-cmds-sourced-script.gdb: New file.

Automatic date update in version.in

Don't let TUI focus on locator

PR tui/26638 notes that the C-x o binding can put the focus on the
locator window.  However, this is not useful and did not happen
historically.  This patch changes the TUI to skip this window when
switching focus.

2020-09-24  Tom Tromey  <tromey@adacore.com>

PR tui/26638:
* tui/tui-stack.h (struct tui_locator_window) <can_focus>: New
method.
* tui/tui-data.h (struct tui_win_info) <can_focus>: New method.
* tui/tui-data.c (tui_next_win): Exclude non-focusable windows.
(tui_prev_win): Rewrite.

gdb/testsuite/ChangeLog
2020-09-24  Tom Tromey  <tromey@adacore.com>

PR tui/26638:
* gdb.tui/list.exp: Check output of "focus next".

Handle 64bit breakpoints of WOW64 processes as SIGINT

When a WOW64 process triggers a breakpoint exception in 64bit code (which
happens when a 64bit gdb calls DebugBreakProcess for a 32bit target),
gdb ignores the breakpoint (because Wow64GetThreadContext can only report
the pc of 32bit code, and there is not int3 at this location).

But if these 64bit breakpoint exceptions are handled as SIGINT, gdb
doesn't check for int3, and always stops the target.

gdb/ChangeLog:

2020-09-23  Hannes Domani  <ssbssa@yahoo.de>

* nat/windows-nat.c (handle_exception): Handle 64bit breakpoints
in WOW64 processes as SIGINT.
* nat/windows-nat.h: Make wow64_process a shared variable.
* windows-nat.c: Remove static wow64_process variable.

gdbserver/ChangeLog:

2020-09-23  Hannes Domani  <ssbssa@yahoo.de>

* win32-low.cc: Remove local wow64_process variable.
* win32-low.h: Remove local wow64_process variable.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb: Update i386_analyze_prologue to skip endbr32

With -m32 -fcf-protection, GCC generates an `endbr32` instruction at the
function entry:

[hjl@gnu-cfl-2 gdb]$ cat /tmp/x.c
int
main(void)
{
  return 0;
}
[hjl@gnu-cfl-2 gdb]$ gcc -g -fcf-protection /tmp/x.c -m32
(gdb) b main
Breakpoint 1 at 0x8049176: file /tmp/x.c, line 3.
(gdb) r
Breakpoint 1, main () at /tmp/x.c:3
3 {
(gdb) disass
Dump of assembler code for function main:
=> 0x08049176 <+0>: endbr32
   0x0804917a <+4>: push   %ebp
   0x0804917b <+5>: mov    %esp,%ebp
   0x0804917d <+7>: mov    $0x0,%eax
   0x08049182 <+12>: pop    %ebp
   0x08049183 <+13>: ret
End of assembler dump.
(gdb)

Update i386_analyze_prologue to skip `endbr32`:

(gdb) b main
Breakpoint 1 at 0x804917d: file /tmp/x.c, line 4.
(gdb) r
Breakpoint 1, main () at /tmp/x.c:4
4   return 0;
(gdb) disass
Dump of assembler code for function main:
   0x08049176 <+0>: endbr32
   0x0804917a <+4>: push   %ebp
   0x0804917b <+5>: mov    %esp,%ebp
=> 0x0804917d <+7>: mov    $0x0,%eax
   0x08049182 <+12>: pop    %ebp
   0x08049183 <+13>: ret
End of assembler dump.
(gdb)

Tested with

$ make check RUNTESTFLAGS="--target_board='unix{-m32,}' i386-prologue-skip-cf-protection.exp"

on Fedora 32/x86-64.

2020-0X-YY  Victor Collod  <vcollod@nvidia.com>

gdb/ChangeLog:

PR gdb/26635
* i386-tdep.c (i386_skip_endbr): Add a helper function to skip endbr.
(i386_analyze_prologue): Call i386_skip_endbr.

gdb/testsuite/ChangeLog:

PR gdb/26635
* gdb.arch/amd64-prologue-skip-cf-protection.exp: Make the test
compatible with i386, and move it to...
* gdb.arch/i386-prologue-skip-cf-protection.exp: ... here.
* gdb.arch/amd64-prologue-skip-cf-protection.c: Move to...
* gdb.arch/i386-prologue-skip-cf-protection.c: ... here.

Automatic date update in version.in