gdb/ChangeLog:

	* infrun.h (debug_infrun): Make a bool.
	* infrun.c (debug_infrun): Make a bool.
	(_initialize_infrun): Use add_setshow_boolean_cmd to define "set
	debug infrun".

Change-Id: If934106a6d3f879b93d265855eb705b1d606339a

The same pattern happens often to define a "debug_printf" macro:

    #define displaced_debug_printf(fmt, ...) \
      do \
        { \
          if (debug_displaced) \
    	debug_prefixed_printf ("displaced", __func__, fmt, ##__VA_ARGS__); \
        } \
      while (0)

Move this pattern behind a helper macro, debug_prefixed_printf_cond and
update the existing macros to use it.

gdb/ChangeLog:

	* displaced-stepping.h (displaced_debug_printf): Use
	debug_prefixed_printf_cond.
	* dwarf2/read.c (dwarf_read_debug_printf): Likewise.
	(dwarf_read_debug_printf_v): Likewise.
	* infrun.h (infrun_debug_printf): Likewise.
	* linux-nat.c (linux_nat_debug_printf): Likewise.

gdbsupport/ChangeLog:

	* common-debug.h (debug_prefixed_printf_cond): New.
	* event-loop.h (event_loop_debug_printf): Use
	debug_prefixed_printf_cond.

Change-Id: I1ff48b98b8d1cc405d1c7e8da8ceadf4e3a17f99

When running test-case gdb.arch/i386-mpx-call.exp with target board unix/-m32,
we run into:
...
(gdb) continue^M
Continuing.^M
(gdb) FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
...

Let's look first for reference at -m64, where the test passes.

The test-case uses -mmpx -fcheck-pointer-bounds to generate pointer checks in
the exec.  Effectively, -fcheck-pointer-bounds modifies the calling ABI: a
call passes pointer bounds as well as arguments.  The call to upper (with
four pointer arguments and an int argument, passed in 5 registers) is modified
like this:
...
   lea    -0xa0(%rbp),%rcx
   lea    -0x80(%rbp),%rdx
   lea    -0x60(%rbp),%rsi
   lea    -0x40(%rbp),%rax
   mov    $0x0,%r8d
+  bndmov -0x110(%rbp),%bnd3
+  bndmov -0x100(%rbp),%bnd2
+  bndmov -0xf0(%rbp),%bnd1
+  bndmov -0xe0(%rbp),%bnd0
   mov    %rax,%rdi
-  callq  <upper>
+  bnd callq <upper>
...
passsing the four pointer bounds in bounds registers BND0-3.

The top-level mechanism of the test is as follows:
- run the exec to after all mallocs are done, such that all pointer variables
  are valid
- do inferior calls, similar to those present in the program

The inferior call mechanism doesn't differentiate between a call to a function
compiled with -fcheck-pointer-bounds, and one without.  It merely resets the
bound registers to all-allowed state (see amd64_push_dummy_call), to make sure
the checks don't trigger during the inferior call.  [ This is the same as what
happens when executing a call without bnd prefix when the BNDPRESERVE bit of
the BNDCFG register is set to 0, a provision for calling an instrumented
function using a non-instrumented call. ]

First, two inferior calls are done (default_run and verify_default_values)
with the bound registers unmodified by the test.  So, the memory accesses are
performed with the bounds registers set by amd64_push_dummy_call to
all-allowed, and the bounds checks do not trigger.

Then we try to do an inferior call with modified bounds registers, set to
none-allowed.  In order to do that, we set a breakpoint at *upper before
doing the inferior call.  Once we hit the breakpoint during the inferior call,
the bounds registers are set to none-allowed, and we continue expecting to run
into an triggered bounds check, which takes the shape of a sigsegv.

Back to -m32.  Here, the pointer arguments are passed in memory rather than
registers, so with -fcheck-pointer-bounds, the pointer bounds are placed in
the Bounds Table using bndstx:
...
  movl   $0x0,0x10(%eax)
  lea    -0x70(%ebp),%edx
  mov    %edx,0xc(%eax)
  lea    -0x5c(%ebp),%edx
  mov    %edx,0x8(%eax)
  lea    -0x48(%ebp),%edx
  mov    %edx,0x4(%eax)
  lea    -0x34(%ebp),%edx
  mov    %edx,(%eax)
  lea    0xc(%eax),%edx
  mov    0xc(%eax),%ecx
  bndmov -0xa8(%ebp),%bnd1
  bndstx %bnd1,(%edx,%ecx,1)
  lea    0x8(%eax),%edx
  mov    0x8(%eax),%ecx
  bndmov -0xa0(%ebp),%bnd3
  bndstx %bnd3,(%edx,%ecx,1)
  lea    0x4(%eax),%edx
  mov    0x4(%eax),%ecx
  bndmov -0x98(%ebp),%bnd1
  bndstx %bnd1,(%edx,%ecx,1)
  mov    (%eax),%edx
  bndmov -0x90(%ebp),%bnd3
  bndstx %bnd3,(%eax,%edx,1)
  bnd call 804893f <upper>
...

Again, the bounds registers are reset at the start of the inferior call by
amd64_push_dummy_call, and modified by the test-case, but neither has any
effect.  The code in upper reads the pointer bounds from the Bounds Table, not
from the bounds registers.

Note that for a test.c with an out-of-bounds access:
...
$ cat test.c
void foo (int *a) { volatile int v = a[1]; }
int main (void) { int a; foo (&a); return 0; }
$ gcc test.c -mmpx -fcheck-pointer-bounds -g -m32
$ ./a.out
Saw a #BR! status 1 at 0x804848d
...
and inferior call foo (&a) right before "bnd call foo" (at the point that the
bounds for a are setup in the bounds table) doesn't trigger a bounds violation:
...
(gdb) call foo (&a)
(gdb)
...
This is because the bounds table doesn't associate a pointer with bounds, but
rather a pair of pointer and pointer location.  So, the bound is setup for &a,
with as location the pushed argument in the frame.  The inferior call however
executes in a dummy frame, so the bound is checked for &a with as location the
pushed argument in the dummy frame, which is different, so the bounds check
doesn't trigger.

In conclusion, this is expected behaviour.

Update the test-case to not expect to override effective pointer bounds using
the bounds registers when the bounds passing is done via the Bounds Table.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-12-11  Tom de Vries  <tdevries@suse.de>

	PR testsuite/26991
	* gdb.arch/i386-mpx-call.exp: Don't expect to trigger bounds
        violations by setting bounds registers if the bounds are passed in the
        Bounds Table.

I noticed that some of the lexers were calling write_dollar_variable
from the lexer.  This seems like a bad practice, so this patch moves
the side effects into the parsers.

I tested this by re-running gdb.fortran and gdb.modula2; the Pascal
compiler on my machine seems not to work, so I couldn't test
gdb.pascal.

I note that the type-tracking in the Pascal is also incorrect, in that
a convenience variable's type may change between parsing and
evaluation (or even during the course of evaluation).

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

	* p-exp.y (intvar): Remove global.
	(DOLLAR_VARIABLE): Change type.
	(start): Update.
	(exp): Call write_dollar_variable here...
	(yylex): ... not here.
	* m2-exp.y (DOLLAR_VARIABLE): Change type.
	(variable): Call write_dollar_variable here...
	(yylex): ... not here.
	* f-exp.y (DOLLAR_VARIABLE): Change type.
	(exp): Call write_dollar_variable here...
	(yylex): ... not here.

	PR 27047
	* config/tc-z80.c (s_bss): New function.
	(md_pseudo_table): Add bss entry.

I noticed that install_variable will never return false, so this patch
changes the return type to void.  I couldn't find a spot in history
where it did return false, maybe it's always been like this.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

	* varobj.c (varobj_create): Update.
	(install_variable): Return void.

This changes instantiate_pretty_printer to use gdbpy_ref, removing a
call to Py_DECREF.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

	* varobj.c (instantiate_pretty_printer): Use gdbpy_ref.

One call to varobj_clear_saved_item is from the varobj destructor.
This is no longer needed, so this patch removes the call; then inlines
the function into the sole remaining caller.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

	* varobj.c (varobj_clear_saved_item): Remove.
	(update_dynamic_varobj_children): Update.
	(varobj::~varobj): Don't call varobj_clear_saved_item.

This changes varobj_item::value to be a value_ref_ptr, removing some
manual management.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

	* varobj.c (install_dynamic_child, varobj_clear_saved_item)
	(update_dynamic_varobj_children, create_child)
	(create_child_with_value): Update.
	* varobj-iter.h (struct varobj_item) <value>: Now a
	value_ref_ptr.
	* python/py-varobj.c (py_varobj_iter::next): Call release_value.

This changes varobj_dynamic::child_iter to be a unique_ptr, removing
some manual management.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

	* varobj.c (struct varobj_dynamic) <child_iter>: Now unique_ptr.
	(varobj_get_iterator): Return unique_ptr.
	(update_dynamic_varobj_children, install_visualizer)
	(varobj::~varobj): Update.
	* python/python-internal.h (py_varobj_get_iterator): Return
	unique_ptr.
	* python/py-varobj.c (py_varobj_get_iterator): Return unique_ptr.

This changes varobj_dynamic::saved_item to be a unique_ptr.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

	* varobj.c (struct varobj_dynamic) <saved_item>: Now unique_ptr.
	(varobj_clear_saved_item, update_dynamic_varobj_children):
	Update.

This changes varobj_iter::next to return a unique_ptr.  This fits in
with the ongoing theme of trying to express these ownership transfers
via the type system.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

	* varobj.c (update_dynamic_varobj_children): Update.
	* varobj-iter.h (struct varobj_iter) <next>: Change return type.
	* python/py-varobj.c (struct py_varobj_iter) <next>: Change return
	type.
	(py_varobj_iter::next): Likewise.

This changes the varobj iteration code to use a C++ class rather than
a C struct with a separate "ops" structure.  The only implementation
is updated to use inheritance.  This simplifies the code quite nicely.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

	* varobj.c (update_dynamic_varobj_children, install_visualizer)
	(varobj::~varobj): Update.
	* varobj-iter.h (struct varobj_iter): Change to interface class.
	(struct varobj_iter_ops): Remove.
	(varobj_iter_next, varobj_iter_delete): Remove.
	* python/py-varobj.c (struct py_varobj_iter): Derive from
	varobj_iter.  Add constructor, destructor.  Rename members.
	(py_varobj_iter::~py_varobj_iter): Rename from
	py_varobj_iter_dtor.
	(py_varobj_iter::next): Rename from py_varobj_iter_next.
	(py_varobj_iter_ops): Remove.
	(py_varobj_iter): Rename from py_varobj_iter_ctor.
	(py_varobj_iter_new): Remove.
	(py_varobj_get_iterator): Update.

This changes all_root_varobjs to take a function_view.  This
simplifies some of the callers, in particular we can remove a data
type that only existed to be passed through.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

	* varobj.h (all_root_varobjs): Take a function_view.
	* varobj.c (all_root_varobjs): Take a function_view.
	(varobj_invalidate_iter): Remove unused parameter.
	(varobj_invalidate): Update.
	* mi/mi-cmd-var.c (struct mi_cmd_var_update): Remove.
	(mi_cmd_var_update_iter): Change parameters.

This changes varobj.c:rootlist to be a std::list.  This lets us remove
some code.  std::list is chosen because its iterator invalidation
approach suits the all_root_varobjs API.

I considered replacing all_root_varobjs with "external iteration", but
haven't gotten around to doing so.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

	* varobj.c (struct varobj_root) <next>: Remove.
	(struct vlist): Remove.
	(rootlist): Now a std::list.
	(install_variable, uninstall_variable, all_root_varobjs): Update.

varobj.c currently has its own hash table implementation.  This patch
replaces it with htab_t, simplifying the code.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

	* varobj.c (VAROBJ_TABLE_SIZE): Remove.
	(varobj_table): Now htab_t.
	(varobj_get_handle, install_variable, uninstall_variable):
	Update.
	(hash_varobj, eq_varobj_and_string): New functions.
	(hash_varobj): Update.

This changes bp_location to derive from refcounted_object, introduces
a ref_ptr specialization for this type, and then changes
bpstats::bp_location_at to use that specialization.  This removes some
manual reference counting and simplifies the code.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

	* inline-frame.c (stopped_by_user_bp_inline_frame): Update.
	* ada-lang.c (check_status_exception): Update.
	* breakpoint.c (free_bp_location): Remove.
	(decref_bp_location): Use bp_location_ref_policy.
	(bpstats::bpstats): Don't call incref_bp_location.
	(bpstats::~bpstats): Remove.
	(bpstats::bpstats): Update.
	(bpstat_check_watchpoint, bpstat_check_breakpoint_conditions)
	(bp_location::bp_location): Update.
	(incref_bp_location): Remove.
	(bkpt_print_it): Update.
	* breakpoint.h (class bp_location): Derive from
	refcounted_object.
	(struct bpstats): Remove destructor.
	<bp_location_at>: Now a bp_location_ref_ptr.
	<refc>: Remove.
	(bp_location_ref_ptr): New typedef.
	(struct bp_location_ref_policy): New.

We can remove scoped_inc_dec_ref by changing the sole user to instead
keep a vector of thread_info_ref objects.  This removes some manual
reference counting and simplifies the code a bit.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

	* thread.c (class scoped_inc_dec_ref): Remove.
	(tp_array_compar_ascending, tp_array_compar_descending): Change
	parameter types.
	(thread_apply_all_command): Use thread_info_ref.

This changes stop_context to use a thread_info_ref, removing some
manual reference counting.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

	* infrun.c (struct stop_context) <thread>: Now a thread_info_ref.
	(stop_context::stop_context): Update.
	(stop_context::~stop_context): Remove.

This changes current_inferior_ to be an inferior_ref, removing some
manual reference counting.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

	* inferior.c (current_inferior_): Change type.
	(current_inferior, set_current_inferior, initialize_inferiors):
	Update.

This changes enable_thread_stack_temporaries to use a thread_info_ref,
removing some manual reference counting.

gdb/ChangeLog
2020-12-11  Tom Tromey  <tom@tromey.com>

	* gdbthread.h (class enable_thread_stack_temporaries) <m_thr>:
	Change type.

The Ravenscar support assumes that the thread ID is the same as the
CPU ID that appears in the Ada task structure.  However, on some
systems, gdbserver will report thread IDs that are off by some
constant.  This can happen, e.g., with qemu in a scenario where there
is an additional (unreported) CPU in the emulation.

The Ada Ravenscar runtimes have been modified to store this offset in
a global variable.  This patch changes gdb to read this variable, when
it exists, and apply the offset to the base CPU ID.  This fixes some
crashes that otherwise occur.

2020-12-11  Tom Tromey  <tromey@adacore.com>

	* ada-tasks.c (struct ada_tasks_pspace_data) <cpu_id_offset>: New
	field.
	(ada_get_tcb_types_info): Look for __gnat_gdb_cpu_first_id.
	(read_atcb): Use cpu_id_offset.

	* ar.c (write_archive): Cast iostream pointer to FILE *.
	* arsup.c (ar_save): Likewise.
	* objcopy.c (copy_file): Likewise.

When configuring gdb using --with-mpfr=no and running test-case
gdb.base/float128.exp, we run into:
...
FAIL: gdb.base/float128.exp: print large128 (GDB may be missing MPFR support!)
...

Fix this by detecting that gdb was build without mpfr using the show
configuration command, and changing the FAIL into UNSUPPORTED.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-12-11  Tom de Vries  <tdevries@suse.de>

	PR testsuite/26954
	* gdb.base/float128.exp: Detect and handle no mpfr support.

That test fails intermittently for me.  The problem is a race condition
between the exec syscall and GDB resuming threads.

The initial situation is that we have two threads, let's call them
"leader" and "other".  Leader is the one who is going to do the exec.
We stop at the breakpoint on the all_started function, so both threads
are stopped.  When resuming, GDB resumes leader first and other second.
However, between resuming the two threads, leader has time to run and do
its exec, making other disappear.  When GDB tries to resume other, it is
ino longer there.  We get some "Couldn't get registers: No such
process." messages, and the state is a bit messed up.

The issue can be triggered consistently by adding a small delay after
the resume syscall:

    diff --git a/gdb/inf-ptrace.c b/gdb/inf-ptrace.c
    index d5a062163c7..9540339a9da 100644
    --- a/gdb/inf-ptrace.c
    +++ b/gdb/inf-ptrace.c
    @@ -308,6 +308,8 @@ inf_ptrace_target::resume (ptid_t ptid, int step, enum gdb_signal signal)
       gdb_ptrace (request, ptid, (PTRACE_TYPE_ARG3)1, gdb_signal_to_host (signal));
       if (errno != 0)
         perror_with_name (("ptrace"));
    +  for (int i = 0 ; i < 100; i++)
    +    usleep (10000);
     }

     /* Wait for the child specified by PTID to do something.  Return the

This patch is about fixing the test to avoid this, since the test is not
about testing this particular corner case.  Handling of multi-threaded
program doing execs should be improved too, but that's not the goal of
this patch.

Fix it by adding a synchronization point in the test to make sure both
threads were resumed by GDB before doing the exec.  I added two
pthread_barrier_wait calls in each thread (for a total of three).  I
think adding one call in each thread would not be enough, because this
could happen:

- both threads reach the first barrier
- the "other" thread is scheduled so has time to run and hit the second
  barrier
- the "leader" thread hits the all_started function breakpoint, causing
  both threads to be stopped by GDB
- GDB resumes the "leader" thread
- Since the "other" thread has already reached the second barrier, the
  "leader" thread is free to run past its second barrier and do the
  exec, while GDB still hasn't resumed the second one

By adding two barrier calls in each thread, I think we are good.  The test
passes consistently for me, even with the artificial delay added.

gdb/testsuite/ChangeLog:

	PR gdb/24694
	* gdb.multi/multi-arch-exec.c (thread_start, main): Add barrier
	calls.

Change-Id: I25c8ea9724010b6bf20b42691c716235537d0e27

In commit 4d91ddd3 "[gdb/testsuite] Fix unbalanced braces in
gdb.tui/new-layout.exp", I tried to fix a problem with test-case
gdb.tui/new-layout.exp when running with tcl 8.5.

However, at that point I only had access to the log containing the failure,
and unfortunately my patch turned out not to be effective.

So, finally fix this problem by guarding the problematic code with:
...
if { [tcl_version_at_least 8 6] } { ... }
...

Tested on x86_64-linux, specifically SLE-11 where I ran into the failure.

gdb/testsuite/ChangeLog:

2020-12-10  Tom de Vries  <tdevries@suse.de>

	PR testsuite/26947
	* gdb.tui/new-layout.exp: Don't execute tests with unbalanced curly
	braces for tcl 8.5 and earlier.

I'm seeing a libstdc++ assertion failure when running GDB's "maint selftest"
command when GDB is configured with the following CFLAGS and CXXFLAGS as
part of the configure line:

  CFLAGS='-D_GLIBCXX_DEBUG -g3 -O0' CXXFLAGS='-D_GLIBCXX_DEBUG -g3 -O0'

This is what I see when running the self tests:

(gdb) maint selftest
Running selftest aarch64-analyze-prologue.
Running selftest aarch64-process-record.
Running selftest arm-record.
Running selftest arm_analyze_prologue.
Running selftest array_view.
Running selftest child_path.
Running selftest cli_utils.
Running selftest command_structure_invariants.
Running selftest copy_bitwise.
Running selftest copy_integer_to_size.
Running selftest cp_remove_params.
Running selftest cp_symbol_name_matches.
Running selftest dw2_expand_symtabs_matching.
/usr/include/c++/11/string_view:211: constexpr const value_type& std::basic_string_view<_CharT, _Traits>::operator[](std::basic_string_view<_CharT, _Traits>::size_type) const [with _CharT = char; _Traits = std::char_traits<char>; std::basic_string_view<_CharT, _Traits>::const_reference = const char&; std::basic_string_view<_CharT, _Traits>::size_type = long unsigned int]: Assertion '__pos < this->_M_len' failed.
Aborted (core dumped)

Here's a partial stack trace:

  #0  0x00007ffff6ef6262 in raise () from /lib64/libc.so.6
  #1  0x00007ffff6edf8a4 in abort () from /lib64/libc.so.6
  #2  0x00000000004249bf in std::__replacement_assert (
      __file=0xef7480 "/usr/include/c++/11/string_view", __line=211,
      __function=0xef7328 "constexpr const value_type& std::basic_string_view<_CharT, _Traits>::operator[](std::basic_string_view<_CharT, _Traits>::size_type) const [with _CharT = char; _Traits = std::char_traits<char>; std::ba"...,
      __condition=0xef7311 "__pos < this->_M_len")
      at /usr/include/c++/11/x86_64-redhat-linux/bits/c++config.h:2624
  #3  0x0000000000451737 in std::basic_string_view<char, std::char_traits<char> >::operator[] (this=0x7fffffffc200, __pos=8)
      at /usr/include/c++/11/string_view:211
  #4  0x00000000004329f5 in ada_fold_name (name="function")
      at /ironwood1/sourceware-git/rawhide-master/bld/../../worktree-master/gdb/ada-lang.c:988

And, looking at frame #4...

(top-gdb) up 4
    at /ironwood1/sourceware-git/rawhide-master/bld/../../worktree-master/gdb/ada-lang.c:988
988		fold_buffer[i] = tolower (name[i]);
(top-gdb) p i
$1 = 8
(top-gdb) p name.size()
$2 = 8

My patch adjusts the comparison to only copy name.size() characters
from the string.  I've added a separate statement for NUL character
termination of fold_buffer[].

gdb/ChangeLog:

	* ada-lang.c (ada_fold_name): Fix off-by-one error.

I noticed a spurious newline on infrun debugging output. The following patch
fixes that. I'll push as obvious.

gdb/ChangeLog:

2020-12-10  Luis Machado  <luis.machado@linaro.org>

	* breakpoint.c (should_be_inserted): Don't output newline.

The FPSIMD dump in signal frames and ptrace FPSIMD dump in the SVE context
structure follows the target endianness, whereas the SVE dumps are
endianness-independent (LE).

Therefore, when the system is in BE mode, we need to reverse the bytes
for the FPSIMD data.

Given the V registers are larger than 64-bit, I've added a way for value
bytes to be set, as opposed to passing a 64-bit fixed quantity. This fits
nicely with the unwinding *_got_bytes function and makes the trad-frame
more flexible and capable of saving larger registers.

The memory for the bytes is allocated via the frame obstack, so it gets freed
after we're done inspecting the frame.

gdb/ChangeLog:

2020-12-10  Luis Machado  <luis.machado@linaro.org>

	* aarch64-linux-tdep.c (aarch64_linux_restore_vreg) New function.
	(aarch64_linux_sigframe_init): Call aarch64_linux_restore_vreg.
	* aarch64-tdep.h (V_REGISTER_SIZE): Move to ...
	* arch/aarch64.h: ... here.
	* nat/aarch64-sve-linux-ptrace.c: Include endian.h.
	(aarch64_maybe_swab128): New function.
	(aarch64_sve_regs_copy_to_reg_buf)
	(aarch64_sve_regs_copy_from_reg_buf): Adjust FPSIMD entries.
	* trad-frame.c (trad_frame_reset_saved_regs): Initialize
	the data field.
	(TF_REG_VALUE_BYTES): New enum value.
	(trad_frame_value_bytes_p): New function.
	(trad_frame_set_value_bytes): New function.
	(trad_frame_set_reg_value_bytes): New function.
	(trad_frame_get_prev_register): Handle register values saved as bytes.
	* trad-frame.h (trad_frame_set_reg_value_bytes): New prototype.
	(struct trad_frame_saved_reg) <data>: New field.
	(trad_frame_set_value_bytes): New prototype.
	(trad_frame_value_bytes_p): New prototype.

This function allows to create a BFD handle using an accessible memory
range in a target memory.  It is currently contained in a JIT module but
this functionality may be of wider usefullness - for example, reading
ELF binaries contained within a core dump.

gdb/ChangeLog:
2020-12-07  Mihails Strasuns  <mihails.strasuns@intel.com>

	* jit.c (mem_bfd*, bfd_open_from_target_memory): Removed.
	* gdb_bfd.h (gdb_bfd_open_from_target_memory): New function.
	* gdb_bfd.c (mem_bfd*, gdb_bfd_open_from_target_memory): New functions.

https://github.com/riscv/riscv-asm-manual/pull/61

We aleady have sext.w, so just add sext.b, sext.h, zext.b, zext.h
and zext.w.  In a certain sense, zext.b is not a pseudo - It is an
alias of andi.  Similarly, sext.b and sext.h are aliases of other
rvb instructions, when we enable b extension; But they are pseudos
when we just enable rvi.  However, this patch does not consider the
rvb cases.  Besides, zext.w is only valid in rv64.

gas/
    * config/tc-riscv.c (riscv_ext): New function.  Use md_assemblef
    to expand the zext and sext pseudos, to give them a chance to be
    expanded into c-ext instructions.
    (macro): Handle M_ZEXTH, M_ZEXTW, M_SEXTB and M_SEXTH.
    * testsuite/gas/riscv/ext.s: New testcase.
    * testsuite/gas/riscv/ext-32.d: Likewise.
    * testsuite/gas/riscv/ext-64.d: Likewise.
include/
    * opcode/riscv.h (M_ZEXTH, M_ZEXTW, M_SEXTB, M_SEXTH.): Added.
opcodes/
    * riscv-opc.c (riscv_opcodes): Add sext.[bh] and zext.[bhw].

opcodes/
    * disassemble.h (riscv_get_disassembler): Declare.
    * disassemble.c (disassembler): Changed to riscv_get_disassembler.
    * riscv-dis.c (riscv_get_disassembler): Check the elf privileged spec
    attributes before calling print_insn_riscv.
    (parse_riscv_dis_option): Same as the assembler, the priority of elf
    attributes are higher than the options.  If we find the privileged
    attributes, but the -Mpriv-spec= is different, then output error/warning
    and still use the elf attributes set.

bfd/
    * elfxx-riscv.c (riscv_ext_dont_care_version): New function.  Return
    TRUE if we don't care the versions of the extensions.  These extensions
    are added to the subset list for special purposes, with the explicit
    versions or the RISCV_UNKNOWN_VERSION versions.
    (riscv_parse_add_subset): If we do care the versions of the extension,
    and the versions are unknown, then report errors for the non-implicit
    extensions, and return directly for the implicit one.
    (riscv_arch_str1): Do not output i extension after e, and the extensions
    which versions are unknown.
gas/
    * config/tc-riscv.c (riscv_multi_subset_supports): Handle INSN_CLASS_ZICSR
    and INSN_CLASS_ZIFENCEI.
    * testsuite/gas/riscv/march-imply-i.s: New testcase.
    * testsuite/gas/riscv/march-imply-i2p0-01.d: New testcase.  The version
    of i is less than 2.1, and zi* are supported in the chosen spec, so
    enable the fence.i and csr instructions, also output the implicit zi* to
    the arch string.
    * testsuite/gas/riscv/march-imply-i2p0-02.d: Likewise, but the zi* are
    not supported in the spec 2.2.  Enable the related instructions since
    i's version is less than 2.1, but do not output them.
    * testsuite/gas/riscv/march-imply-i2p1-01.d: New testcase.  The version
    of i is 2.1, so don't add it's implicit zi*, and disable the related
    instructions.
    * testsuite/gas/riscv/march-imply-i2p1-01.l: Likewise.
    * testsuite/gas/riscv/march-imply-i2p1-02.d: Likewise, and set the zi*
    explicitly, so enable the related instructions.
    * testsuite/gas/riscv/march-imply-i2p0.d: Removed.
    * testsuite/gas/riscv/march-imply-i2p1.d: Removed.
include/
    * opcode/riscv.h: Add INSN_CLASS_ZICSR and INSN_CLASS_ZIFENCEI.
opcodes/
    * riscv-opc.c (riscv_opcodes): Control fence.i and csr instructions by
    zifencei and zicsr.

Joel recently pointed out add_angle_brackets to me.  This patch
changes one spot in ada-lang.c to use this function rather than doing
it on its own.

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

	* ada-lang.c (ada_lookup_encoded_symbol): Use add_angle_brackets.

In some cases, GNAT can emit 128-bit constants for fixed-point types.
This patch changes gdb to handle this scenario, by changing the
low-level rational-reading functions in dwarf2/read.c to work directly
with gdb_mpz values.  (I'm not sure offhand if these 128-bit patches
have gone into upstream GCC yet -- but they will eventually, and
meanwhile I think it should be clear that this patch is otherwise
harmless.)

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

	* dwarf2/read.c (get_dwarf2_rational_constant): Change "numerator"
	and "denominator" to gdb_mpz.  Handle block forms.
	(get_dwarf2_unsigned_rational_constant): Change "numerator" and
	"denominator" to gdb_mpz.
	(finish_fixed_point_type): Update.
	(has_zero_over_zero_small_attribute): Update.

This removes ada-operator.def and fortran-operator.def, merging their
contents into std-operator.def.

Note that the comment for OP_EXTENDED0 is a bit wrong.  IMO this
constant could be removed, as it is only used for a single assert that
does not provide much value.  However, I haven't done so here.

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

	* expprint.c (op_name): Update.
	* expression.h (enum exp_opcode): Update.
	* std-operator.def: Add more opcodes.
	* ada-operator.def, fortran-operator.def: Remove, moving contents
	into std-operator.def.

I forgot to include fixes for review comments I got before pushing the
previous commits (or I pushed the wrong commits).  This one fixes it.

 - Return {} instead of false in get_discrete_low_bound and
   get_discrete_high_bound.
 - Compute high bound after confirming low bound is valid in
   get_discrete_bounds.

gdb/ChangeLog:

	* gdbtypes.c (get_discrete_low_bound, get_discrete_high_bound):
	Return {} instead of false.
	(get_discrete_bounds): Compute high bound only if low bound is
	valid.

Change-Id: I5f9a66b3672adfac9441068c899ab113ab2c331a

Since commit 7c6f2712 ("gdb: make get_discrete_bounds check for
non-constant range bounds"), subscripting  flexible array member fails:

    struct no_size
    {
      int n;
      int items[];
    };

    (gdb) p *ns
    $1 = {n = 3, items = 0x5555555592a4}
    (gdb) p ns->items[0]
    Cannot access memory at address 0xfffe555b733a0164
    (gdb) p *((int *) 0x5555555592a4)
    $2 = 101  <--- we would expect that
    (gdb) p &ns->items[0]
    $3 = (int *) 0xfffe5559ee829a24  <--- wrong address

Since the flexible array member (items) has an unspecified size, the array type
created for it in the DWARF doesn't have dimensions (this is with gcc 9.3.0,
Ubuntu 20.04):

    0x000000a4:   DW_TAG_array_type
                    DW_AT_type [DW_FORM_ref4]       (0x00000038 "int")
                    DW_AT_sibling [DW_FORM_ref4]    (0x000000b3)

    0x000000ad:     DW_TAG_subrange_type
                      DW_AT_type [DW_FORM_ref4]     (0x00000031 "long unsigned int")

This causes GDB to create a range type (TYPE_CODE_RANGE) with a defined
constant low bound (dynamic_prop with kind PROP_CONST) and an undefined
high bound (dynamic_prop with kind PROP_UNDEFINED).

value_subscript gets both bounds of that range using
get_discrete_bounds.  Before commit 7c6f2712, get_discrete_bounds
didn't check the kind of the dynamic_props and would just blindly read
them as if they were PROP_CONST.  It would return 0 for the high bound,
because we zero-initialize the range_bounds structure.  And it didn't
really matter in this case, because the returned high bound wasn't used
in the end.

Commit 7c6f2712 changed get_discrete_bounds to return a failure if
either the low or high bound is not a constant, to make sure we don't
read a dynamic prop that isn't a PROP_CONST as a PROP_CONST.  This
change made get_discrete_bounds start to return a failure for that
range, and as a result would not set *lowp and *highp.  And since
value_subscript doesn't check get_discrete_bounds' return value, it just
carries on an uses an uninitialized value for the low bound.  If
value_subscript did check the return value of get_discrete_bounds, we
would get an error message instead of a bogus value.  But it would still
be a bug, as we wouldn't be able to print the flexible array member's
elements.

Looking at value_subscript, we see that the low bound is always needed,
but the high bound is only needed if !c_style.  So, change
value_subscript to use get_discrete_low_bound and
get_discrete_high_bound separately.  This fixes the case described
above, where the low bound is known but the high bound isn't (and is not
needed).  This restores the original behavior without accessing a
dynamic_prop in a wrong way.

A test is added.  In addition to the case described above, a case with
an array member of size 0 is added, which is a GNU C extension that
existed before flexible array members were introduced.  That case
currently fails when compiled with gcc <= 8.  gcc <= 8 produces DWARF
similar to the one shown above, while gcc 9 adds a DW_AT_count of 0 in
there, which makes the high bound known.  A case where an array member
of size 0 is the only member of the struct is also added, as that was
how PR 28675 was originally reported, and it's an interesting corner
case that I think could trigger other funny bugs.

Question about the implementation: in value_subscript, I made it such
that if the low or high bound is unknown, we fall back to zero.  That
effectively makes it the same as it was before 7c6f2712.  But should
we instead error() out?

gdb/ChangeLog:

	PR 26875, PR 26901
	* gdbtypes.c (get_discrete_low_bound): Make non-static.
	(get_discrete_high_bound): Make non-static.
	* gdbtypes.h (get_discrete_low_bound): New declaration.
	(get_discrete_high_bound): New declaration.
	* valarith.c (value_subscript): Only fetch high bound if
	necessary.

gdb/testsuite/ChangeLog:

	PR 26875, PR 26901
	* gdb.base/flexible-array-member.c: New test.
	* gdb.base/flexible-array-member.exp: New test.

Change-Id: I832056f80e6c56f621f398b4780d55a3a1e299d7