[gdb/symtab] Handle DW_AT_ranges with DW_FORM_sec_off in partial DIE

While looking into a failure in gdb.go/package.exp with gcc-11, I noticed that
gdb shows some complaints when loading the executable (also with gcc-10, where
the test-case passes):
...
$ gdb -batch -iex "set complaints 100" package.10 -ex start
During symbol reading: Attribute value is not a constant (DW_FORM_sec_offset)
Temporary breakpoint 1 at 0x402ae6: file gdb.go/package1.go, line 8.
During symbol reading: Attribute value is not a constant (DW_FORM_sec_offset)
During symbol reading: Invalid .debug_rnglists data (no base address)
...

Fix this by using as_unsigned () to read DW_AT_ranges in the partial DIE
reader, similar to how that is done in dwarf2_get_pc_bounds.

Tested on x86_64-linux.

gdb/ChangeLog:

2021-01-25  Bernd Edlinger  <bernd.edlinger@hotmail.de>
    Simon Marchi  <simon.marchi@polymtl.ca>
    Tom de Vries  <tdevries@suse.de>

* dwarf2/read.c (partial_die_info::read): Use as_unsigned () for
DW_AT_ranges.

gdb/testsuite/ChangeLog:

2021-01-25  Tom de Vries  <tdevries@suse.de>

* gdb.dwarf2/dw2-ranges-psym.exp (gdb_load_no_complaints): New proc.
* lib/gdb.exp: Use gdb_load_no_complaints.

gdb/docs: add parentheses in Python examples using print

This makes the examples work both in Python 2 and 3.

gdb/doc/ChangeLog:

* python.texi: Add parentheses to print statements/functions.

Change-Id: I8571f2ee005acd96c7bb43f9882d19b00b2aa3db

Fix fixed-point regression with recent GCC

A recent version of GCC changed how fixed-point types are described.
For example, a denominator in one test case now looks like:

    GNU_denominator      (exprloc)
     [ 0] implicit_value: 16 byte block: 00 00 b8 9d 0d 69 55 a0 01 00 00 00 00 00 00 00

... the difference being that this now uses exprloc and emits a
DW_OP_implicit_value for the 16-byte block.  (DWARF 5 still uses
DW_FORM_data16.)

This change was made here:

    https://gcc.gnu.org/pipermail/gcc-patches/2020-December/560897.html

This patch updates gdb to handle this situation.

Note that, before GCC 11, this test would not give the same answer.
Earlier versions of GCC fell back to GNAT encodings for this case.

gdb/ChangeLog
2021-01-25  Tom Tromey  <tromey@adacore.com>

* dwarf2/read.c (get_mpz): New function.
(get_dwarf2_rational_constant): Use it.

gdb/testsuite/ChangeLog
2021-01-25  Tom Tromey  <tromey@adacore.com>

* gdb.ada/fixed_points.exp: Add regression test.
* gdb.ada/fixed_points/fixed_points.adb (FP5_Var): New variable.
* gdb.ada/fixed_points/pck.adb (Delta5, FP5_Type): New.

Specially handle array contexts in Ada expression resolution

A user noticed that the Ada expression code in gdb did not
automatically disambiguate an enumerator in an array context.  That
is, an expression like "print array(enumerator)" is not ambiguous,
even if "enumerator" is declared in multiple enumerations, because the
correct one can be found by examining the array's index type.

This patch changes the Ada expression resolution code to handle this
case.

gdb/ChangeLog
2021-01-25  Tom Tromey  <tromey@adacore.com>

* ada-lang.c (resolve_subexp): Handle array context.

gdb/testsuite/ChangeLog
2021-01-25  Tom Tromey  <tromey@adacore.com>

* gdb.ada/local-enum.exp: Add enumerator resolution test.

Add test case for symbol menu for local enumerators

Ada will normally present a menu to the user to allow manual
disambiguation of symbols.  The AdaCore internal GDB had a bug that
prevented this from happening.  Although this bug is not in the FSF
GDB, it seemed worthwhile to write a test case to ensure this.

gdb/testsuite/ChangeLog
2021-01-25  Tom Tromey  <tromey@adacore.com>

* gdb.ada/local-enum.exp: New file.
* gdb.ada/local-enum/local.adb: New file.

Add some more DWARF-5 sections

gdb/doc: move @menu blocks to the end of their enclosing @node

The @menus should be at the end of a @node.  We mostly get this right,
but there's a few places where we don't.  This commit fixes the 5
places we get this wrong.

I manually checked the info page and read each of the offending nodes
after this change and I believe they all still make sense with the
menu moved.

gdb/doc/ChangeLog:

* gdb.texinfo (Specify Location): Move menu to the end of the
node.
(Auto-loading): Likewise.
(Extending GDB): Likewise.
(TUI): Likewise.
(Operating System Information): Likewise.

Update linker scripts with the names of new DWARF-5 debug sections.

* scripttempl/DWARF.sc: Add .debug_loclists, .debug_rnglists,
.debug_line_str and .debug_str_offsets.  Move .debug_macro and
.debug_addr into DWARF-5 section.

Automatic date update in version.in

DWARF-5: Ignore empty range in DWARF-5 line number tables

The DWARF5 spec does indeed explicitly say: "A bounded range entry whose
beginning and ending address offsets are equal (including zero) indicates
an empty range and may be ignored."

Since arange_add already ignores empty ranges, remove the whole check
which is equivalent to the check plus explicit continue.

PR binutils/27231
* dwarf2.c (read_rnglists): Ignore empty range when parsing line
number tables.

gas: Add a testcase for PR gas/27228

PR gas/27228
* testsuite/gas/elf/elf.exp: Run pr27228.
* testsuite/gas/elf/pr27228.d: New file.
* testsuite/gas/elf/pr27228.s: Likewise.

Minor updates to the 'how to make a release' document

PR27228, .reloc wrong symbol emitted for undefined local symbol

Local symbols are of course supposed to be defined by their object
file, but in other cases a local symbol is promoted to global by gas
if undefined and referenced.  This patch stops gas wrongly replacing a
local undefined symbol with the undefined section symbol, resulting in
a .reloc undefined local symbol being emitted as global.

PR 27228
* write.c (resolve_reloc_expr_symbols): Don't assume local symbol
is defined.

Avoid crash when "compile" expression uses cooked register

If the "compile" command is used with an expression that happens to
require a cooked register, then GDB can crash.  This patch does not
fix the bug, but at least turns the crash into an error instead.

2021-01-23  Tom Tromey  <tom@tromey.com>

PR compile/25575
* compile/compile-loc2c.c (note_register): New function.
(pushf_register_address, pushf_register): Use it.

Use std::vector for "registers_used" in compile feature

This changes the GDB compile code to use std::vector<bool> when
computing which registers are used.  This is a bit more idiomatic, but
the main benefit is that it also adds some checking when the libstd++
debug mode is enabled.

2021-01-23  Tom Tromey  <tom@tromey.com>

* symtab.h (struct symbol_computed_ops) <generate_c_location>:
Change type of "registers_used".
* dwarf2/loc.h (dwarf2_compile_property_to_c): Update.
* dwarf2/loc.c (dwarf2_compile_property_to_c)
(locexpr_generate_c_location, loclist_generate_c_location): Change
type of "registers_used".
* compile/compile.h (compile_dwarf_expr_to_c)
(compile_dwarf_bounds_to_c): Update.
* compile/compile-loc2c.c (pushf_register_address)
(pushf_register, do_compile_dwarf_expr_to_c)
(compile_dwarf_expr_to_c, compile_dwarf_bounds_to_c): Change type
of "registers_used".
* compile/compile-c.h (generate_c_for_variable_locations):
Update.
* compile/compile-c-symbols.c (generate_vla_size)
(generate_c_for_for_one_variable): Change type of
"registers_used".
(generate_c_for_variable_locations): Return std::vector.
* compile/compile-c-support.c (generate_register_struct): Change
type of "registers_used".
(compute): Update.

DWARF-5: Fix parsing DWARF-5 line number tables

Advance rngs_ptr when parsing DW_RLE_offset_pair, which was missing in

commit c3757b583d2448a5996e83e374fb96ac7938da35
Author: Mark Wielaard <mark@klomp.org>
Date:   Tue Aug 25 15:33:00 2020 +0100

    Fix the linker's handling of DWARF-5 line number tables.

PR binutils/27231
* dwarf2.c (read_rnglists): Advance rngs_ptr after
_bfd_safe_read_leb128 when parsing DW_RLE_offset_pair.

Remove call to reset from compile_to_object

compile_to_object declares 'error_message' and then immediately calls
reset on it.  It seemed better to change it to use initialization
instead; and then I noticed that set_arguments could return a
unique_xmalloc_ptr<char> itself.

2021-01-23  Tom Tromey  <tom@tromey.com>

* compile/compile-internal.h (class compile_instance)
<set_arguments>: Change return type.
* compile/compile.c (compile_to_object): Remove call to reset.
(compile_instance::set_arguments): Change return type.

Automatic date update in version.in

gdb: fix regression in copy_type_recursive

Commit 5b7d941b90d1 ("gdb: add owner-related methods to struct type")
introduced a regression when running gdb.base/jit-reader-simple.exp and
others.  A NULL pointer dereference happens here:

    #3  0x0000557b7e9e8650 in gdbarch_obstack (arch=0x0) at /home/simark/src/binutils-gdb/gdb/gdbarch.c:484
    #4  0x0000557b7ea5b138 in copy_type_recursive (objfile=0x614000006640, type=0x62100018da80, copied_types=0x62100018e280) at /home/simark/src/binutils-gdb/gdb/gdbtypes.c:5537
    #5  0x0000557b7ea5dcbb in copy_type_recursive (objfile=0x614000006640, type=0x62100018e200, copied_types=0x62100018e280) at /home/simark/src/binutils-gdb/gdb/gdbtypes.c:5598
    #6  0x0000557b802cef51 in preserve_one_value (value=0x6110000b3640, objfile=0x614000006640, copied_types=0x62100018e280) at /home/simark/src/binutils-gdb/gdb/value.c:2518
    #7  0x0000557b802cf787 in preserve_values (objfile=0x614000006640) at /home/simark/src/binutils-gdb/gdb/value.c:2562
    #8  0x0000557b7fbaf19b in reread_symbols () at /home/simark/src/binutils-gdb/gdb/symfile.c:2489
    #9  0x0000557b7ec65d1d in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at /home/simark/src/binutils-gdb/gdb/infcmd.c:439
    #10 0x0000557b7ec67a97 in run_command (args=0x0, from_tty=1) at /home/simark/src/binutils-gdb/gdb/infcmd.c:546

This is inside a TYPE_ALLOC macro.  The fact that gdbarch_obstack is
called means that the type is flagged as being arch-owned, but arch=0x0
means that type::arch returned NULL, probably meaning that the m_owner
field contains NULL.

If we look at the code before the problematic patch, in the
copy_type_recursive function, we see:

    if (! TYPE_OBJFILE_OWNED (type))
      return type;

    ...

    TYPE_OBJFILE_OWNED (new_type) = 0;
    TYPE_OWNER (new_type).gdbarch = get_type_arch (type);

The last two lines were replaced with:

    new_type->set_owner (type->arch ());

get_type_arch and type->arch isn't the same thing: get_type_arch gets
the type's arch owner if it is arch-owned, and gets the objfile's arch
if the type is objfile owned.  So it always returns non-NULL.
type->arch returns the type's arch if the type is arch-owned, else NULL.
So since the original type is objfile owned, it effectively made the new
type arch-owned (that is good) but set the owner to NULL (that is bad).

Fix this by using get_type_arch again there.

I spotted one other similar change in lookup_array_range_type, in the
original patch.  But that one appears to be correct, as it is executed
only if the type is arch-owned.

Add some asserts in type::set_owner to ensure we never set a NULL owner.
That would have helped catch the issue a little bit earlier, so it could
help in the future.

gdb/ChangeLog:

* gdbtypes.c (copy_type_recursive): Use get_type_arch.
* gdbtypes.h (struct type) <set_owner>: Add asserts.

Change-Id: I5d8bc7bfc83b3abc579be0b5aadeae4241179a00

Improve gdb_tilde_expand logic.

Before this patch, gdb_tilde_expand would use glob(3) in order to expand
tilde at the begining of a path. This implementation has limitation when
expanding a tilde leading path to a non existing file since glob fails to
expand.

This patch proposes to use glob only to expand the tilde component of the
path and leaves the rest of the path unchanged.

This patch is a followup to the following discution:
https://sourceware.org/pipermail/gdb-patches/2021-January/174776.html

Before the patch:

gdb_tilde_expand("~") -> "/home/lsix"
gdb_tilde_expand("~/a/c/b") -> error() is called

After the patch:

gdb_tilde_expand("~") -> "/home/lsix"
gdb_tilde_expand("~/a/c/b") -> "/home/lsix/a/c/b"

Tested on x84_64 linux.

gdb/ChangeLog:

* Makefile.in (SELFTESTS_SRCS): Add
unittests/gdb_tilde_expand-selftests.c.
* unittests/gdb_tilde_expand-selftests.c: New file.

gdbsupport/ChangeLog:

* gdb_tilde_expand.cc (gdb_tilde_expand): Improve
implementation.
(gdb_tilde_expand_up): Delegate logic to gdb_tilde_expand.
* gdb_tilde_expand.h (gdb_tilde_expand): Update description.

Use readline's variant of Windows patch

A while back, Eli sent a patch to readline that was incorporated by
upstream readline in a slightly different form.  To cut down on
divergences between GDB and upstream readline, I am checking in this
patch to use the readline code.

readline/readline/ChangeLog.gdb
2021-01-23  Tom Tromey  <tom@tromey.com>

* input.c [_WIN32]: Use code from upstream readline.

Disable bracketed paste mode in GDB tests

I have a patch to import GNU readline 8.1 into GDB.  However, when
running the tests, there were a number of failures due to "bracketed
paste mode".  This is a terminal feature that readline 8.1 enables by
default.

The simplest way to work around this was to always make a ".inputrc"
for GDB tests that will tell readline to disable brackted paste mode.

gdb/testsuite/ChangeLog
2021-01-23  Tom Tromey  <tom@tromey.com>

* lib/gdb.exp (default_gdb_init): Set INPUTRC to a cached file.

Automatic date update in version.in

Fix expected output of gdb.base/line65535.exp with dwarf-5

With gcc & binutils built from latest git revision
this test case fails because the output of the break
command changes and contains the full path name of
the source file, while previously only the file name
was printed.

Fixed that by adjusting the test expectation.

2021-01-22  Bernd Edlinger  <bernd.edlinger@hotmail.de>

* gdb.base/line65535.exp: Fix test expectation.

gdb/testsuite: eliminate gdb_suppress_tests mechanism

There is a lot of support code for the test suppression mechanism.  But
as far as I know, it is not useful.  The gdb_suppress_tests proc is in
fact disabled with this comment that has been there since forever:

    return;  # fnf - disable pending review of results where
             # testsuite ran better without this

I suggest to just remove everything related to test suppression, that
removes some unnecessary complexity from the support code and the tests.

gdb/testsuite/ChangeLog:

* lib/gdb.exp (gdb_test_multiple): Remove things related to test
suppression.
(default_gdb_exit): Likewise.
(default_gdb_spawn): Likewise.
(send_gdb): Likewise.
(gdb_expect): Likewise.
(gdb_expect_list): Likewise.
(default_gdb_init): Likewise.
(gdb_suppress_entire_file): Remove.
(gdb_suppress_tests): Remove.
(gdb_stop_suppressing_tests): Remove.
(gdb_clear_suppressed): Remove.
* lib/mi-support.exp (mi_uncatched_gdb_exit): Remove things
related to test suppression.
(default_mi_gdb_start): Likewise.
(mi_gdb_reinitialize_dir): Likewise.
(mi_gdb_test): Likewise.
(mi_run_cmd_full): Likewise.
(mi_runto_helper): Likewise.
(mi_execute_to): Likewise.
* lib/prompt.exp (default_prompt_gdb_start): Likewise.
* gdb.base/bitfields.exp: Likewise.
* gdb.base/bitfields2.exp: Likewise.
* gdb.base/break.exp: Likewise.
* gdb.base/call-sc.exp: Likewise.
* gdb.base/callfuncs.exp: Likewise.
* gdb.base/dfp-test.exp: Likewise.
* gdb.base/endian.exp: Likewise.
* gdb.base/exprs.exp: Likewise.
* gdb.base/funcargs.exp: Likewise.
* gdb.base/hbreak2.exp: Likewise.
* gdb.base/recurse.exp: Likewise.
* gdb.base/scope.exp: Likewise.
* gdb.base/sepdebug.exp: Likewise.
* gdb.base/structs.exp: Likewise.
* gdb.base/until.exp: Likewise.
* gdb.cp/misc.exp: Likewise.

Change-Id: Ie6d3025091691ba72010faa28b85ebd417b738f7

gdb: add new version style

This commit adds a new 'version' style, which replaces the hard coded
styling currently used for GDB's version string.  GDB's version number
is displayed:

  1. In the output of 'show version', and

  2. When GDB starts up (without the --quiet option).

This new style can only ever affect the first of these two cases as
the second case is printed before GDB has processed any initialization
files, or processed any GDB commands passed on the command line.

However, because the first case exists I think this commit makes
sense, it means the style is no longer hard coded into GDB, and we can
add some tests that the style can be enabled/disabled correctly.

This commit is an alternative to a patch Tom posted here:

  https://sourceware.org/pipermail/gdb-patches/2020-June/169820.html

I've used the style name 'version' instead of 'startup' to reflect
what the style is actually used for.  If other parts of the startup
text end up being highlighted I imagine they would get their own
styles based on what is being highlighted.  I feel this is more inline
with the other style names that are already in use within GDB.

I also decoupled adding this style from the idea of startup options,
and the possibility of auto-saving startup options.  Those ideas can
be explored in later patches.

This commit should probably be considered only a partial solution to
issue PR cli/25956.  The colours of the style are no longer hard
coded, however, it is still impossible to change the styling of the
version string displayed during startup, so in one sense, the styling
of that string is still "hard coded".  A later patch will hopefully
extend GDB to allow it to adjust the version styling before the
initial version string is printed.

gdb/ChangeLog:

PR cli/25956
* cli/cli-style.c: Add 'cli/cli-setshow.h' include.
(version_style): Define.
(cli_style_option::cli_style_option): Add intensity parameter, and
use as appropriate.
(_initialize_cli_style): Register version style set/show commands.
* cli/cli-style.h (cli_style_option): Add intensity parameter.
(version_style): Declare.
* top.c (print_gdb_version): Use version_stype, and styled_string
to print the GDB version string.

gdb/doc/ChangeLog:

PR cli/25956
* gdb.texinfo (Output Styling): Document version style.

gdb/testsuite/ChangeLog:

PR cli/25956
* gdb.base/style.exp (run_style_tests): Add version string test.
(test_startup_version_string): Use version style name.
* lib/gdb-utils.exp (style): Handle version style name.

gdb: don't print escape characters when a style is disabled

While working on another patch I noticed that if I disable a single
style with, for example:

  set style filename background none
  set style filename foreground none
  set style filename intensity normal

Then in some places escape characters are still injected into the
output stream.  This is a bit of an edge case, and I can't think when
this would actually cause problems, but it still felt like a bit of an
annoyance.

One place where this does impact is in testing, where it becomes
harder to write tight test patterns if it is not obvious when GDB will
decide to inject escape sequences.

It's especially annoying because depending on how something is printed
then GDB might, or might not, add escape characters.  So this would
not add escape characters if the filename style was disabled:

  fprintf_filtered (file, "%ps",
                    styled_string (file_name_style.style (),
                                   "This is a test"));

But this would add escape characters:

  fprintf_styled (file, file_name_style.style (),
                  "%s", "This is a test");

I tracked this down to some calls to set_output_style in utils.c.
Currently some calls to set_output_style (in utils.c) are guarded like
this:

  if (!STYLE.is_default ())
    set_output_style (stream, STYLE);

But some calls are not.  It is the calls that are NOT guarded that
cause the extra escape sequences to be emitted.

My initial proposal to resolve this issue was simply to ensure that
all calls to set_output_style were guarded.  The patch I posted for
this can be found here:

  https://sourceware.org/pipermail/gdb-patches/2021-January/175096.html

The feedback on this proposal was that it might be better to guard
against the escape sequences being emitted at a later lever, right
down at emit_style_escape.

So this is what this version does.  In emit_style_escape we already
track the currently applied style, so if the style we are being asked
to switch to is the same as the currently applied style then no escape
sequence needs to be emitted.

Making this change immediately exposed some issues in
fputs_maybe_filtered related to line wrapping.  The best place to start
to understand what's going on with the styling and wrapping is look at
the test:

  gdb.base/style.exp: all styles enabled: frame when width=20

If you run this test and then examine the output in an editor so the
escape sequences can be seen you'll see the duplicate escape sequences
that are emitted before this patch, the compare to after this patch
you'll see the set of escape sequences should be the minimum required.

In order to test these changes I have rewritten the gdb.base/style.exp
test script.  The core of the script is now run multiple times.  The
first time the test is run things are as they were before, all styles
are on.

After that the test is rerun multiple times.  Each time through a
single style is disabled using the 3 explicit set calls listed above.
I then repeat all the tests, however, I arrange so that the patterns
for the disabled style now require no escape sequences.

gdb/ChangeLog:

* utils.c (emit_style_escape): Only emit an escape sequence if the
requested style is different than the current applied style.
(fputs_maybe_filtered): Adjust the juggling of the wrap_style, and
current applied_style.
(fputs_styled): Remove is_default check.
(fputs_styled_unfiltered): Likewise.
(vfprintf_styled_no_gdbfmt): Likewise.

gdb/testsuite/ChangeLog:

* gdb.base/style.exp (limited_style): New proc.
(clean_restart_and_disable): New proc.
(run_style_tests): New proc.  Most of the old tests from this file
are now in this proc.
(test_startup_version_string): New proc.  Reamining test from the
old file is in this proc.

gdb/doc: don't rely on @menu item within the docs

The node 'Auto-loading extensions' currently relies on a @menu item to
provide a set of cross-references to different parts of the manual.
Additionally the menu is placed part way through the node and the text
prior to the menu seems (to me) to assume that the menu will be
formatted into the document.

This is a bad idea as the menus are not always part of the final
document (e.g. pdf output does not include the menu), when compared to
the info page the pdf version of this node is less helpful as it lacks
proper cross references.  Menus should always be placed at the end of
a node.

In this commit I rewrite a paragraph to add extra cross references
inline within the text.  I then move the menu to the end of the node.

gdb/doc/ChangeLog:

* gdb.texinfo (Auto-loading extensions): Add additional cross
references and move @menu to the end of the node.

gdb: add remote_debug_printf

This is the next in the new-style debug macro series.

For this one, I decided to omit the function name from the "Sending packet" /
"Packet received" kind of prints, just because it's not very useful in that
context and hinders readability more than anything else.  This is completely
arbitrary.

This is with:

  [remote] putpkt_binary: Sending packet: $qTStatus#49...
  [remote] getpkt_or_notif_sane_1: Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes::

and without:

  [remote] Sending packet: $qTStatus#49...
  [remote] Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes::

A difference is that previously, the query packet and its reply would be
printed on the same line, like this:

  Sending packet: $qTStatus#49...Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes::

Now, they are printed on two lines, since each remote_debug_printf{,_nofunc}
prints its own complete message including an end of line.  It's probably
a matter of taste, but I prefer the two-line version, it's easier to
follow, especially when the query packet is long.

As a result, lib/range-stepping-support.exp needs to be updated, as it
currently expects the vCont packet and the reply to be on the same line.
I think it's sufficient in that context to just expect the vCont packet
and not the reply, since the goal is just to count how many vCont;r GDB
sends.

gdb/ChangeLog:

* remote.h (remote_debug_printf): New.
(remote_debug_printf_nofunc): New.
(REMOTE_SCOPED_DEBUG_ENTER_EXIT): New.
* remote.c: Use above macros throughout file.

gdbsupport/ChangeLog:

* common-debug.h (debug_prefixed_printf_cond_nofunc): New.
* common-debug.c (debug_prefixed_vprintf): Handle a nullptr
func.

gdb/testsuite/ChangeLog:

* lib/range-stepping-support.exp (exec_cmd_expect_vCont_count):
Adjust to "set debug remote" changes.

Change-Id: Ica6dead50d3f82e855c7d763f707cef74bed9fee

gdb: change remote_debug to bool

As far as I can see, there are no more spots looking for a remote_debug
other than true/false.  If we ever want to revert to an int, we can
always change it back later, but this makes things simpler for now.

gdb/ChangeLog:

* remote.h (remote_debug): Change to bool.
* remote.c (remote_debug): Change to bool.
(_initialize_remote): Adjust.

Change-Id: I21aac5b4cff9dc4f75c8efaf47c23583ecabd2a6

gdb: move remote_debug to remote.{h,c}

remote_debug is currently declared in target.h and defined in top.c.
Move them to remote.h and remote.c.

Include remote.h in remote-sim.c, as it uses remote_debug.

gdb/ChangeLog:

* target.h (remote_debug): Move to...
* remote.h (remote_debug): ... here.
* top.c (remote_debug): Move to...
* remote.c (remote_debug): ... here.
* remote-sim.c: Include remote.h.

Change-Id: Iae632d12ff8900b23eee6b2529d6a3cd339a8caa

gdb: move set remote commands to remote.c

Commands "set debug remote" and "set remotetimeout" are defined in
cli/cli-cmds.c, I think it would make more sense for them to be in
remote.c.

gdb/ChangeLog:

* cli/cli-cmds.c (show_remote_debug): Remove.
(show_remote_timeout): Remove.
(_initialize_cli_cmds): Don't register commands.
* remote.c (show_remote_debug): Move here.
(show_remote_timeout): Move here.
(_initialize_remote): Register commands.

Change-Id: Ic4d81888aa4f8dde89d1d29397ef19a08951b80b

gdb: remove TYPE_OBJFILE macro

Change all users to use the type::objfile method instead.

gdb/ChangeLog:

* gdbtypes.h (TYPE_OBJFILE): Remove, change all users to use the
type::objfile method instead.

Change-Id: I6b3f580913fb1fb0cf986b176dba8db68e1fabf9

gdb: remove TYPE_OBJFILE_OWNED macro

Update all users to use the type::is_objfile_owned method.

gdb/ChangeLog:

* gdbtypes.h (TYPE_OBJFILE_OWNED): Remove, update all users to
use the type::is_objfile_owned method.

Change-Id: Icae84d136393ab9f756f50a33ac3cedda13c5ba2

gdb: add owner-related methods to struct type

Add the following methods to struct type:

 * is_objfile_owned
 * set_owner (objfile and gdbarch overloads)
 * objfile and arch getters

Rename the fields in main_type to ensure no other code accesses them
directly.  As usual, we can't make them actually private, but giving
them the `m_` prefix will help making sure they are not accessed when
not supposed to, by convention.

Remove the TYPE_OWNER macro to ensure no code uses the type_owner struct
directly.

gdb/ChangeLog:

* gdbtypes.h (TYPE_OBJFILE_OWNED): Adjust.
(TYPE_OWNER): Remove.
(TYPE_OBJFILE): Adjust.
(struct main_type) <flag_objfile_owned>: Rename to...
<m_flag_objfile_owned>: ... this.
<owner>: Rename to...
<m_owner>: ... this.
(struct type) <is_objfile_owned, set_owner, objfile, arch>: New
methods.
(TYPE_ALLOC): Adjust.
* gdbtypes.c (alloc_type): Adjust.
(alloc_type_arch): Adjust.
(alloc_type_copy): Adjust.
(get_type_arch): Adjust.
(smash_type): Adjust.
(lookup_array_range_type): Adjust.
(recursive_dump_type): Adjust.
(copy_type_recursive): Adjust.
* compile/compile-c-types.c (convert_func): Adjust.
(convert_type_basic): Adjust.
* compile/compile-cplus-types.c (compile_cplus_convert_func):
Adjust.
* language.c
(language_arch_info::type_and_symbol::alloc_type_symbol):
Adjust.

Change-Id: I7f92e869d9f92e2402a3d3007dd0832e05aa6ac8

gdb/doc: move @menu to the end of the node

Commit:

  commit a72d0f3d69896b5fcdc916e0547fe774dcb58614
  Date:   Tue Jan 12 13:02:30 2021 +0000

      gdb/doc: reorder and group sections relating to aliases

Added a @menu block into the wrong place within a @node.  This commit
moves it to the end of the @node, where it should be been placed.

gdb/doc/ChangeLog:

* gdb.texinfo (Aliases): Move @menu to the end of the node.

gdb/doc: down case contents of @var

After a discussion on a recent patch it was pointed out that the
contents of a @var should (generally) be lower case.  I took a look
through the GDB manual and there are a small number of places where
the contents are currently upper case, but one in particular seemed
like an obvious candidate for being down cased, so lets do that.

gdb/doc/ChangeLog:

* gdb.texinfo (PowerPC Embedded): Down case contents of @var.

MAINTAINERS: Update my e-mail address

binutils/
* MAINTAINERS: Update my e-mail address.

gdb/
* MAINTAINERS: Update my e-mail address.

sim/
* MAINTAINERS: Update my e-mail address.

Automatic date update in version.in

Handle additional connection error

On Ubuntu 18.04/20.04 I was running into annoying timeouts for
gdb.server/server-connect.exp. Those were caused by the ipv6 tests, because
they were running into the "Cannot assign requested address" error, originated
from the connect syscall.

Improve this by handling this additional error in the testsuite library.

It still fails for me, but at least it fails pretty quickly and doesn't make the
testsuite run take longer.

gdb/testsuite/ChangeLog:

2021-01-21  Luis Machado  <luis.machado@linaro.org>

* lib/gdbserver-support.exp (gdb_target_cmd_ext): Handle a new error
message.

Fix build errors for armhf

When building for 32-bit ARM, I ran into a couple build failures.

The first one seems to be caused by recent changes to warning switches,
leading to the following error:

--
In file included from gdb/coffread.c:35:0:
gdb/coffread.c: In function  "void enter_linenos(file_ptr, int, int, objfile*)":
gdb/complaints.h:40:40: error: format "%ld" expects argument of type "long int", but argument 2 has type "file_ptr {aka long long int}" [-Werror=format=]
  complaint_internal (FMT, ##__VA_ARGS__);  \
                                        ^
gdb/coffread.c:1413:7: note: in expansion of macro "complaint"
       complaint (_("Line number pointer %ld lower than start of line numbers"),
       ^~~~~~~~~
--

The other one is due to a narrowing conversion in valops.c:

--
gdb/valops.c: In function "value* value_assign(value*, value*)":
gdb/gdbtypes.h:1798:43: error: narrowing conversion of "type->type::length" from "ULONGEST {aka long long unsigned int}" to "size_t {aka unsigned int}" inside { } [-Werror=narrowing]
 #define TYPE_LENGTH(thistype) (thistype)->length
                               ~~~~~~~~~~~~^
gdb/valops.c:1252:9: note: in expansion of macro "TYPE_LENGTH"
         TYPE_LENGTH (type)});
--

Fix both with the following patch. Validated with --enable-targets=all on
Ubuntu 18.04/20.04.

gdb/ChangeLog:

2021-01-21  Luis Machado  <luis.machado@linaro.org>

* coffread.c (enter_linenos): Passing string to complaint.
* valops.c (value_assign): Make array view.

gdb: convert auto-load to new-style debug macros

Function file_is_auto_load_safe was taking a format string and varargs
just to output a debug print.  This is probably because that function is
used in linux-thread-db.c and main.c, but debug_auto_load is static in
auto-load.c.  I simplified that, making debug_auto_load visible outside
of auto-load.c, and making the callers of file_is_auto_load_safe output
the debug print themselves.

This file uses _() for internationalization of the debug messages.  This
is not necessary, as these are mostly messages for GDB developers, and
it's not used in other files anyway.  So I removed them.

The rest is pretty much standard.

gdb/ChangeLog:

* auto-load.h (debug_auto_load): Move here.
(auto_load_debug_printf): New.
* auto-load.c: Use auto_load_debug_printf.
(debug_auto_load): Move to header.
* linux-thread-db.c (try_thread_db_load): Use
auto_load_debug_printf.
* main.c (captured_main_1): Likewise.

Change-Id: I468dc2a1d24b7dbf171f55181a11abbfafe70ba1

gdb: remove unused f77_array_offset_tbl from f-valprint.c

This variable appears to be unused.  Its uses were removed in commit
3e2e34f8623d ("fort_dyn_array: Use value constructor instead of
raw-buffer manipulation.") back in 2016.

gdb/ChangeLog:

* f-valprint.c (f77_array_offset_tbl): Remove.

Change-Id: I39ff8d1b402e54ca2ade936f65e540f500cce86e

gdb: convert bfd-cache to new-style debug macros

gdb/ChangeLog:

* gdb_bfd.c (bfd_cache_debug_printf): New, use throughout file.

Change-Id: Ie29948d82adfae7edb3cdcbd61f59a66892fcc99

gdb: use interruptible_select when connecting to a remote

When GDB is waiting trying to connect to a remote target and it receives
a SIGWINCH (terminal gets resized), the blocking system call gets
interrupted and we abort.

For example, I connect to some port (on which nothing listens):

    (gdb) tar rem :1234
    ... GDB blocks here, resize the terminal ...
    :1234: Interrupted system call.

The backtrace where GDB is blocked while waiting for the connection to
establish is:

    #0  0x00007fe9db805b7b in select () from /usr/lib/libc.so.6
    #1  0x000055f2472e9c42 in gdb_select (n=0, readfds=0x0, writefds=0x0, exceptfds=0x0, timeout=0x7ffe8fafe050) at /home/simark/src/binutils-gdb/gdb/posix-hdep.c:31
    #2  0x000055f24759c212 in wait_for_connect (sock=-1, polls=0x7ffe8fafe300) at /home/simark/src/binutils-gdb/gdb/ser-tcp.c:147
    #3  0x000055f24759d0e8 in net_open (scb=0x62500015b900, name=0x6020000601d8 ":1234") at /home/simark/src/binutils-gdb/gdb/ser-tcp.c:356
    #4  0x000055f2475a0395 in serial_open_ops_1 (ops=0x55f24892ca60 <tcp_ops>, open_name=0x6020000601d8 ":1234") at /home/simark/src/binutils-gdb/gdb/serial.c:244
    #5  0x000055f2475a01d6 in serial_open (name=0x6020000601d8 ":1234") at /home/simark/src/binutils-gdb/gdb/serial.c:231
    #6  0x000055f2474d5274 in remote_serial_open (name=0x6020000601d8 ":1234") at /home/simark/src/binutils-gdb/gdb/remote.c:5019
    #7  0x000055f2474d7025 in remote_target::open_1 (name=0x6020000601d8 ":1234", from_tty=1, extended_p=0) at /home/simark/src/binutils-gdb/gdb/remote.c:5571
    #8  0x000055f2474d47d5 in remote_target::open (name=0x6020000601d8 ":1234", from_tty=1) at /home/simark/src/binutils-gdb/gdb/remote.c:4898
    #9  0x000055f24776379f in open_target (args=0x6020000601d8 ":1234", from_tty=1, command=0x611000042bc0) at /home/simark/src/binutils-gdb/gdb/target.c:242

Fix that by using interruptible_select in wait_for_connect, instead of
gdb_select.  Resizing the terminal now no longer aborts the connection.
It is still possible to interrupt the connection using ctrl-c.

gdb/ChangeLog:

* ser-tcp.c (wait_for_connect): Use interruptible_select instead
of gdb_select.

Change-Id: Ie25577bd1e5699e4847b6b53fdfa10b8c0dc5c89

gdb/testsuite: improve logging in lib/tuiterm.exp

Here's a bonus patch that applies on top of the other two.

While debugging TUI test cases, it's hard to know what exactly is
happening in the little mind of the terminal emulator.  Add some logging
for all input processing.  Right now I'm interested in seeing what
happens to the cursor position, so made it so all operations log the
"before" and "after" cursor position.  It should help see if any
operation is not behaving as expected, w.r.t. the cursor position.

Here are some examples of the logging found in gdb.log with this patch
applied:

    +++ Inserting string '+|'
    +++   Inserted char '+', cursor: (0, 79) -> (1, 0)
    +++   Inserted char '|', cursor: (1, 0) -> (1, 1)
    +++ Inserted string '+|', cursor: (0, 79) -> (1, 1)
    +++ Cursor Horizontal Absolute (80), cursor: (1, 1) -> (1, 79)

In the last line, note that the argument is 80 and we move to 79, that's
because the position in the argument to the control sequence is 1-based,
while our indexing is 0-based.

gdb/testsuite/ChangeLog:

* lib/tuiterm.exp (_log, _log_cur): New, use throughout.

Change-Id: Ibf570d4b2867729ce65bea8c193343a8a846170d

gdb/doc: reorder and group sections relating to aliases

This started by observing that the section name:

  Automatically prepend default arguments to user-defined aliases

Is very long.  When this is rendered in the PDF manual (at least for
me), this name is so long that in the table of contents the page
number ends up being misaligned.

My first thought was we could drop the 'to user-defined aliases' bit
if this section became a sub-section of the section on aliases.

So then I looked for a section with 'aliases' in its name, and
couldn't find one.

It turns out that aliases are documented in a section called:

  Creating new spellings of existing commands

Which (to me) seems an odd aspect of aliases to emphasise.

So, in this patch I make the following changes:

  - Move the section on aliases earlier in the manual, this is now
    immediately after the section about creating user defined
    commands.  This made more sense to me.

  - Rename the section on aliases from 'Creating new spellings of
    existing commands' to 'Command Aliases'.

  - Update the wording of the first paragraph in the 'Command Aliases'
    section so that it reads better given the new name.

  - Add a cross-reference from the 'Command Aliases' section to the
    'Python' section now that the aliases section comes first.

  - Down case all the text inside @var within this section as this is
    the correct style for the GDB manual.

  - Move the section on default args to become a sub-section of the
    'Command Aliases' section, and rename this sub-section from
    'Automatically prepend default arguments to user-defined aliases'
    to 'Default Arguments'.

  - Add @menu into the 'Command Aliases' section to link to the
    'Default Arguments' subsection.

  - Add a @cindex entry to the default arguments sub-section.

gdb/doc/ChangeLog:

* gdb.texinfo (Commands): Update menu.
(Extending GDB): Likewise.
(Command aliases default args): Moved later into the document,
added a cindex entry.  Renamed the section 'Automatically prepend
default arguments to user-defined aliases' to 'Default Arguments'.
(Aliases): Moved earlier in the document.  Minor rewording of the
first paragraph, down-cased the text inside all uses of @var, and
added a cross reference to the Python code.  Renamed the section
'Creating new spellings of existing commands' to 'Command
Aliases'.

Add Python support for hardware breakpoints

This allows the creation of hardware breakpoints in Python with
gdb.Breakpoint(type=gdb.BP_HARDWARE_BREAKPOINT)
And they are included in the sequence returned by gdb.breakpoints().

gdb/ChangeLog:

2021-01-21  Hannes Domani  <ssbssa@yahoo.de>

PR python/19151
* python/py-breakpoint.c (bppy_get_location): Handle
bp_hardware_breakpoint.
(bppy_init): Likewise.
(gdbpy_breakpoint_created): Likewise.

gdb/doc/ChangeLog:

2021-01-21  Hannes Domani  <ssbssa@yahoo.de>

PR python/19151
* python.texi (Breakpoints In Python): Document
gdb.BP_HARDWARE_BREAKPOINT.

gdb/testsuite/ChangeLog:

2021-01-21  Hannes Domani  <ssbssa@yahoo.de>

PR python/19151
* gdb.python/py-breakpoint.exp: Add tests for hardware breakpoints.

gdb: convert arm to new-style debug macros

gdb/ChangeLog:

* arm-tdep.c (arm_debug_printf): Add and use throughout file.

Change-Id: Iec5c2955cb79d8c0288ffded2c8a58b7eb7e3554

PR27221, 058430b4a1 warnings while assembling the Linux kernel

PR 27221
* dwarf2dbg.c (dwarf2_gen_line_info_1): Don't warn about ignored
line number info when gas is generating it.
* testsuite/gas/elf/dwarf2-20.d: Adjust to not expect warnings.
* testsuite/gas/m68hc11/indexed12.d: Likewise.
* testsuite/gas/elf/elf.exp: Don't run warn-2.
* gas/testsuite/gas/elf/warn-2.s: Delete.

PR27218, memory access violation in dwarf2dbg.c

PR 27218
* dwarf2dbg.c (dwarf2_gen_line_info): Correct setting of dwarf_level.
(dwarf2_directive_filename, dwarf2_directive_loc): Likewise, and
error for negative file numbers.

mips XPASS pr26936

git commit 994b25132814 "Ignore section symbols when matching linkonce
with comdat" cured the reason why this test used to fail on mips.

* testsuite/ld-elf/pr26936.d: No longer xfail mips.

gdb: change debug_bfd_cache to bool

gdb/ChangeLog:

* gdb_bfd.c (debug_bfd_cache): Change type to bool.
(_initialize_gdb_bfd): Adjust.

Change-Id: I90fdcc2e2d405653d0eba776f316bcec361b2d18

gdb/testsuite: use multi_line in gdb.base/skip.exp

This will make it easier to modify, in particular add some indentation.
It is also a bit nicer to read, in my opinion.

gdb/testsuite/ChangeLog;

* gdb.base/skip.exp: Use multi_line where relevant.

Change-Id: Ia11712aac77344e0b8a836f4181d67e1cad3826c

gdb/dwarf: add assertion in maybe_queue_comp_unit

The symptom that leads to this is the crash described in PR 26828:

/home/simark/src/binutils-gdb/gdb/dwarf2/read.c:23478:25: runtime error: member access within null pointer of type 'struct dwarf2_cu'

The line of the crash is the following, in follow_die_offset:

  if (target_cu != cu)
    target_cu->ancestor = cu;  <--- HERE

The line that assign nullptr to `target_cu` is the `per_objfile->get_cu`
call after having called maybe_queue_comp_unit:

      /* If necessary, add it to the queue and load its DIEs.  */
      if (maybe_queue_comp_unit (cu, per_cu, per_objfile, cu->language))
load_full_comp_unit (per_cu, per_objfile, per_objfile->get_cu (per_cu),
     false, cu->language);

      target_cu = per_objfile->get_cu (per_cu);  <--- HERE

Some background: there is an invariant, documented in
maybe_queue_comp_unit's doc, that if a CU is queued for expansion
(present in dwarf2_per_bfd::queue), then its DIEs are loaded in memory.
"its DIEs are loaded in memory" is a synonym for saying that a dwarf2_cu
object exists for this CU.  Yet another way to say it is that
`per_objfile->get_cu (per_cu)` returns something not nullptr for that
CU.

The crash documented in PR 26828 triggers some hard-to-reproduce
sequence that ends up violating the invariant:

- dwarf2_fetch_die_type_sect_off gets called for a DIE in CU A
- The DIE in CU A requires some DIE in CU B
- follow_die_offset calls maybe_queue_comp_unit.  maybe_queue_comp_unit
  sees CU B is not queued and its DIEs are not loaded, so it enqueues it
  and returns 1 to its caller - meaning "the DIEs are not loaded, you
  should load them" - prompting follow_die_offset to load the DIEs by
  calling load_full_comp_unit
- Note that CU B is enqueued by maybe_queue_comp_unit even if it has
  already been expanded.  It's a bit useless (and causes trouble, see
  next patch), but that's how it works right now.
- Since we entered the dwarf2/read code through
  dwarf2_fetch_die_type_sect_off, nothing processes the queue, so we
  exit the dwarf2/read code with CU B still lingering in the queue.

- dwarf2_fetch_die_type_sect_off gets called for a DIE in CU A, again
- The DIE in CU A requires some DIE in CU B, again
- This time, maybe_queue_comp_unit sees that CU B is in the queue.
  Because of the invariant that if a CU is in the queue, its DIEs are
  loaded in the memory, it returns 0 to its caller, meaning "you don't
  need to load the DIEs!".
- That happens to be true, so everything is fine for now.

- Time passes, some things call dwarf2_per_objfile::age_comp_units
  enough so that CU B's age becomes past the dwarf_max_cache_age
  threshold.  age_comp_units proceeds to free CU B's DIEs.  Remember
  that CU B is still lingering in the queue (oops, the invariant just
  got violated).

- dwarf2_fetch_die_type_sect_off gets called for a DIE in CU A, again
- The DIE in CU A requires some DIE in CU B, again
- maybe_queue_comp_unit sees that CU B is in the queue, so returns to
  its caller "you don't need to load the DIEs!".  However, we know at
  this point this is false.
- follow_die_offset doesn't load the DIEs and tries to obtain the DIEs for
  CU B:

    target_cu = per_objfile->get_cu (per_cu);

  But since they are not loaded, target_cu is nullptr, and we get the
  crash mentioned above a few lines after that.

This patch adds an assertions in maybe_queue_comp_unit to verify the
invariant, to make sure it doesn't return a falsehood to its caller.

The current patch doesn't fix the issue (the next patch does), but it
makes it so we catch the problem earlier and get this assertion failure
instead of a segmentation fault:

    /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:9100: internal-error:
        int maybe_queue_comp_unit(dwarf2_cu*, dwarf2_per_cu_data*, dwarf2_per_objfile*, language):
        Assertion `per_objfile->get_cu (per_cu) != nullptr' failed.

gdb/ChangeLog:

PR gdb/26828
* dwarf2/read.c (maybe_queue_comp_unit): Add assertion.

Change-Id: I4e51bd7bd58773f9fadf480179cbc4bae61508fe

gdb/dwarf: add some logging in dwarf2/read.c

This patch adds some logging that helped me diagnose the problems fixed
later in this series.  I'm thinking that if it helped me now, it could
help somebody else (or myself) in the future, so I might as well add
them for real.

They can happen quite frequently and be noisy, so I used
dwarf_read_debug_printf_v for them, which means they'll only print if
`set debug dwarf-read` is >= 2.

gdb/ChangeLog:

* dwarf2/read.c (follow_die_offset): Add logging.
(dwarf2_per_objfile::age_comp_units): Add logging.

Change-Id: I7483c0b05c37bc9710b9b5d40e272935bc010863

gdb: make some variables static

I'm trying to enable clang's -Wmissing-variable-declarations warning.
This patch fixes all the obvious spots where we can simply add "static"
(at least, found when building on x86-64 Linux).

gdb/ChangeLog:

* aarch64-linux-tdep.c (aarch64_linux_record_tdep): Make static.
* aarch64-tdep.c (tdesc_aarch64_list, aarch64_prologue_unwind,
aarch64_stub_unwind, aarch64_normal_base, ): Make static.
* arm-linux-tdep.c (arm_prologue_unwind): Make static.
* arm-tdep.c (struct frame_unwind): Make static.
* auto-load.c (auto_load_safe_path_vec): Make static.
* csky-tdep.c (csky_stub_unwind): Make static.
* gdbarch.c (gdbarch_data_registry): Make static.
* gnu-v2-abi.c (gnu_v2_abi_ops): Make static.
* i386-netbsd-tdep.c (i386nbsd_mc_reg_offset): Make static.
* i386-tdep.c (i386_frame_setup_skip_insns,
i386_tramp_chain_in_reg_insns, i386_tramp_chain_on_stack_insns):
Make static.
* infrun.c (observer_mode): Make static.
* linux-nat.c (sigchld_action): Make static.
* linux-thread-db.c (thread_db_list): Make static.
* maint-test-options.c (maintenance_test_options_list):
* mep-tdep.c (mep_csr_registers): Make static.
* mi/mi-cmds.c (struct mi_cmd_stats): Remove struct type name.
(stats): Make static.
* nat/linux-osdata.c (struct osdata_type): Make static.
* ppc-netbsd-tdep.c (ppcnbsd_reg_offsets): Make static.
* progspace.c (last_program_space_num): Make static.
* python/py-param.c (struct parm_constant): Remove struct type
name.
(parm_constants): Make static.
* python/py-record-btrace.c (btpy_list_methods): Make static.
* python/py-record.c (recpy_gap_type): Make static.
* record.c (record_goto_cmdlist): Make static.
* regcache.c (regcache_descr_handle): Make static.
* registry.h (DEFINE_REGISTRY): Make definition static.
* symmisc.c (std_in, std_out, std_err): Make static.
* top.c (previous_saved_command_line): Make static.
* tracepoint.c (trace_user, trace_notes, trace_stop_notes): Make
static.
* unittests/command-def-selftests.c (nr_duplicates,
nr_invalid_prefixcmd, lists): Make static.
* unittests/observable-selftests.c (test_notification): Make
static.
* unittests/optional/assignment/1.cc (counter): Make static.
* unittests/optional/assignment/2.cc (counter): Make static.
* unittests/optional/assignment/3.cc (counter): Make static.
* unittests/optional/assignment/4.cc (counter): Make static.
* unittests/optional/assignment/5.cc (counter): Make static.
* unittests/optional/assignment/6.cc (counter): Make static.

gdbserver/ChangeLog:

* ax.cc (bytecode_address_table): Make static.
* debug.cc (debug_file): Make static.
* linux-low.cc (stopping_threads): Make static.
(step_over_bkpt): Make static.
* linux-x86-low.cc (amd64_emit_ops, i386_emit_ops): Make static.
* tracepoint.cc (stop_tracing_bkpt, flush_trace_buffer_bkpt,
alloced_trace_state_variables, trace_buffer_ctrl,
tracing_start_time, tracing_stop_time, tracing_user_name,
tracing_notes, tracing_stop_note): Make static.

Change-Id: Ic1d8034723b7802502bda23770893be2338ab020

gdb/remote.c: address conflicting enum and method name

When building with gcc 4.8, we get:

      CXX    remote.o
    cc1plus: warning: command line option '-Wmissing-prototypes' is valid for C/ObjC but not for C++ [enabled by default]
    /home/smarchi/src/binutils-gdb/gdb/remote.c:1157:38: error: 'resume_state' is not a class, namespace, or enumeration
       enum resume_state m_resume_state = resume_state::NOT_RESUMED;
                                          ^

It looks like gcc 4.8 doesn't like that there is an enum class named
resume_state as well as a method.  Since it's an easy fix, rename the method to
get_remote_state to avoid the clash.

gdb/ChangeLog:

PR gdb/27219
* remote.c (struct remote_thread_info) <resume_state>: Rename
to...
<get_resume_state>: ... this.
(remote_target::resume): Adjust.
(remote_target::commit_resume): Adjust.
(remote_target::select_thread_for_ambiguous_stop_reply): Adjust.

Change-Id: Ib86c877a4c75ee671d69c27ed06cb8f57bc087db

Automatic date update in version.in

gdb/testsuite: rename _cur_x/_cur_y to _cur_col/_cur_row in lib/tuiterm.exp

I am having trouble remembering which of _cur_x/_cur_y is columns and
which is rows, so renaming them helps.  We already have _rows and _cols
to represent the terminal size, so I think that makes sense to name the
"_cur" variables accordingly.

gdb/testsuite/ChangeLog:

* lib/tuiterm.exp: Rename _cur_x/_cur_y to _cur_col/_cur_row.

Change-Id: I6abd3cdfdb295d8abde12dcd5f0ae09f18f07967

gdb/testsuite: add links for handled control sequences in lib/tuiterm.exp

This code can be a bit cryptic for those who don't know terminal control
sequences very well.  This patch adds links for all the handled
sequences, so it's easy to get some doc to follow the code.

I linked to a VT510 manual, because I think it's well formatted and easy
to read.  There's only the repeat sequence (_csi_b) which I haven't
found in it, it looks to be xterm-specific or something.

I also tried to use the sequence names as they are in the manual.

gdb/testsuite/ChangeLog:

* lib/tuiterm.exp: Add links in comments.

Change-Id: I670b947a238e5e9bcab7c476a20eb3c31cf2909d

[gdb/testsuite] Fix gdb.python/py-format-string.exp with -m32

When running test-case gdb.python/py-format-string.exp with target board
unix/-m32, we run into:
...
(gdb) python print \
  (gdb.parse_and_eval ('a_base_ref').format_string (deref_refs=True))^M
@0xffffc468: {_vptr.Base = 0x80487e0 <vtable for Deriv+8>, a = 42, \
              static a_static_member = 2019}^M
(gdb) FAIL: gdb.python/py-format-string.exp: format_string: \
  lang_cpp: a_base_ref with option deref_refs: deref_refs=true
...
while with -m64, we have instead:
...
@0x7fffffffd170: {_vptr.Base = 0x400910 <vtable for Deriv+16>, a = 42, \
                  static a_static_member = 2019}^M
(gdb) PASS: gdb.python/py-format-string.exp: format_string: \
  lang_cpp: a_base_ref with option deref_refs: deref_refs=true
...

The vtable contains pointer entries which are 4-byte for -m32 and 8-byte for
-m64, so it's not surprising the offsets (Deriv+8 vs. Deriv+16) differ.

Fix this by allow Deriv+$decimal.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-01-20  Tom de Vries  <tdevries@suse.de>

* gdb.python/py-format-string.exp: Allow Deriv+$decimal as vtable
offset.

[gdb/testsuite] Skip gdb.rust/*.exp for target board unix/-m32

When running gdb.rust/*.exp with target board unix/-m32, we see:
...
Running src/gdb/testsuite/gdb.rust/union.exp ...
gdb compile failed, error: Unrecognized option: 'm'
Running src/gdb/testsuite/gdb.rust/modules.exp ...
gdb compile failed, error: Unrecognized option: 'm'
Running src/gdb/testsuite/gdb.rust/unsized.exp ...
gdb compile failed, error: Unrecognized option: 'm'
Running src/gdb/testsuite/gdb.rust/simple.exp ...
gdb compile failed, error: Unrecognized option: 'm'
Running src/gdb/testsuite/gdb.rust/watch.exp ...
gdb compile failed, error: Unrecognized option: 'm'
Running src/gdb/testsuite/gdb.rust/traits.exp ...
gdb compile failed, error: Unrecognized option: 'm'
Running src/gdb/testsuite/gdb.rust/expr.exp ...
Running src/gdb/testsuite/gdb.rust/rust-style.exp ...
gdb compile failed, error: Unrecognized option: 'm'
Running src/gdb/testsuite/gdb.rust/methods.exp ...
gdb compile failed, error: Unrecognized option: 'm'
Running src/gdb/testsuite/gdb.rust/generics.exp ...
gdb compile failed, error: Unrecognized option: 'm'
                === gdb Summary ===

nr of expected passes            95
nr of untested testcases         9
...

Fix this by testing for -m32 in the target board multilib_flags in
skip_rust_tests.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-01-20  Tom de Vries  <tdevries@suse.de>

* lib/gdb.exp (skip_rust_tests): Skip if multilib_flags contains -m32.

Fix a few stap parser issues and add a new test for probe expressions

The creation of this patch was motivated by Tom's "Change handling of
'!' operator in stap probes" patch.

While reviewing his patch, I stumbled upon a few issues with the stap
expression parser.  They are:

- As it turns out, even with Tom's patch applied the parser doesn't
  properly handle the '!' operator.  The underlying issue was the fact
  that stap_parse_argument_conditionally also needed to be patched in
  order to recognize '!' as an operator that is part of a single
  operand, and parse it accordingly.

- While writing the testcase I'm proposing on this patch, I found that
  parenthesized sub-expressions were not being parsed correctly when
  there was another term after them.  For example:

    1 - (2 + 3) + 4

  In this case, the parser was considering "1" to be the left-side of
  the expression, and "(2 + 3) + 4" to be the right-side.  The patch
  fixes the parser by making it identify whether a parenthesized
  sub-expression has just been parsed, and act accordingly.

I've tested this on my Debian testing amd64, and everything seems OK.

gdb/ChangeLog:
2021-01-20  Sergio Durigan Junior  <sergiodj@sergiodj.net>
    Tom Tromey <tom@tromey.com>

* stap-probe.c (stap_parse_single_operand): Handle '!'
operator.
(stap_parse_argument_conditionally): Likewise.
Skip spaces after processing open-parenthesis sub-expression.
(stap_parse_argument_1): Skip spaces after call to
stap_parse_argument_conditionally.
Handle case when right-side expression is a parenthesized
sub-expression.
Skip spaces after call to stap_parse_argument_1.

gdb/testsuite/ChangeLog:
2021-01-20  Sergio Durigan Junior  <sergiodj@sergiodj.net>

* gdb.arch/amd64-stap-expressions.S: New file.
* gdb.arch/amd64-stap-expressions.exp: New file.

[gdb/server] Don't overwrite fs/gs_base with -m32

Consider a minimal test-case test.c:
...
int main (void) { return 0; }
...
compiled with -m32:
...
$ gcc test.c -m32
...

When running the exec using gdbserver on openSUSE Factory (currently running a
linux kernel version 5.10.5):
...
$ gdbserver localhost:12345 a.out
...
to which we connect in a gdb session, we run into a segfault in the inferior:
...
$ gdb -batch -q -ex "target remote localhost:12345" -ex continue
Program received signal SIGSEGV, Segmentation fault.
0xf7dd8bd2 in init_cacheinfo () at ../sysdeps/x86/cacheinfo.c:761
...

The segfault is caused by gdbserver overwriting $gs_base with 0 using
PTRACE_SETREGS.  After it is overwritten, the next use of $gs in the inferior
will trigger the segfault.

Before linux kernel version 5.9, the value used by PTRACE_SETREGS for $gs_base
was ignored, but starting version 5.9, the linux kernel has support for
intel architecture extension FSGSBASE, which allows users to modify $gs_base,
and consequently PTRACE_SETREGS can no longer ignore the $gs_base value.

The overwrite of $gs_base with 0 is done by a memset in x86_fill_gregset,
which was added in commit 9e0aa64f551 "Fix gdbserver qGetTLSAddr for
x86_64 -m32".  The memset intends to zero-extend 32-bit registers that are
tracked in the regcache to 64-bit when writing them into the PTRACE_SETREGS
data argument.  But in addition, it overwrites other registers that are
not tracked in the regcache, such as $gs_base.

Fix the segfault by redoing the fix from commit 9e0aa64f551 in minimal form.

Tested on x86_64-linux:
- openSUSE Leap 15.2 (using kernel version 5.3.18):
  - native
  - gdbserver -m32
  - -m32
- openSUSE Factory (using kernel version 5.10.5):
  - native
  - m32

gdbserver/ChangeLog:

2021-01-20  Tom de Vries  <tdevries@suse.de>

* linux-x86-low.cc (collect_register_i386): New function.
(x86_fill_gregset):  Remove memset.  Use collect_register_i386.

PowerPC: Don't generate unused section symbols

PowerPC version of git commit d1bcae833b.

bfd/
* elf32-ppc.c: Delete outdated comment.
(TARGET_KEEP_UNUSED_SECTION_SYMBOLS): Define.
* elf64-ppc.c (TARGET_KEEP_UNUSED_SECTION_SYMBOLS): Define.
gas/
* testsuite/gas/ppc/power4.d: Adjust for removal of section sym.
* testsuite/gas/ppc/test1elf32.d: Likewise.
* testsuite/gas/ppc/test1elf64.d: Likewise.
ld/
* testsuite/ld-powerpc/relbrlt.s: Make symbols global.
* testsuite/ld-powerpc/relbrlt.d: Adjust to suit.
* testsuite/ld-powerpc/tlsget.d: Adjust for reordered stubs.
* testsuite/ld-powerpc/tlsget.wf: Likewise.
* testsuite/ld-powerpc/tlsget2.d: Likewise.
* testsuite/ld-powerpc/tlsget2.wf: Likewise.
* testsuite/ld-powerpc/tlsexe.r: Adjust for removed section syms.
* testsuite/ld-powerpc/tlsexe32.r: Likewise.
* testsuite/ld-powerpc/tlsexe32no.r: Likewise.
* testsuite/ld-powerpc/tlsexeno.r: Likewise.
* testsuite/ld-powerpc/tlsexenors.r: Likewise.
* testsuite/ld-powerpc/tlsexers.r: Likewise.
* testsuite/ld-powerpc/tlsexetoc.r: Likewise.
* testsuite/ld-powerpc/tlsexetocrs.r: Likewise.
* testsuite/ld-powerpc/tlsso.r: Likewise.
* testsuite/ld-powerpc/tlsso32.r: Likewise.
* testsuite/ld-powerpc/tlstocso.r: Likewise.

PowerPC64 synthetic symbols

If an assembler trims off unused section symbols there may be no
section symbols.  This means that testing for the .opd section symbol
needs to test both the section name and symbol flags.

* elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Don't assume
section symbols are present.

Automatic date update in version.in

use DISABLE_COPY_AND_ASSIGN in switch_thru_all_uis

In switch_thru_all_uis,  a pre-c++11 way of removing copy constructor
and assignment operator is used.

This patch uses the DISABLE_COPY_AND_ASSIGN macro which does the right
thing for pre and post c++11.

gdb/Changelog:

2021-01-19  Lancelot SIX  <lsix@lancelotsix.com>

* top.h (switch_thru_all_uis): Use DISABLE_COPY_AND_ASSIGN.

trad-frame cleanups

With the new member functions for struct trad_frame_saved_reg, there is no
need to invoke some of the set/get functions anymore.  This patch removes
those and adjusts all callers.

Even though the most natural initial state of a saved register value is
UNKNOWN, there are target backends relying on the previous initial state
of REALREG set to a register's own number. I noticed this in at least a
couple targets: aarch64 and riscv.

Because of that, I decided to keep the reset function that sets the set of
register values to REALREG. I can't exercise all the targets to make sure
the initial state change won't break things, hence why it is risky to change
the default.

Validated with --enable-targets=all on aarch64-linux Ubuntu 18.04/20.04.

gdb/ChangeLog

2021-01-19  Luis Machado  <luis.machado@linaro.org>

* trad-frame.h (trad_frame_saved_reg) <set_value_bytes>: Allocate
memory and save data.
(trad_frame_set_value, trad_frame_set_realreg, trad_frame_set_addr)
(trad_frame_set_unknown, trad_frame_set_value_bytes)
(trad_frame_value_p, trad_frame_addr_p, trad_frame_realreg_p)
(trad_frame_value_bytes_p): Remove.
(trad_frame_reset_saved_regs): Adjust documentation.
* trad-frame.c (trad_frame_alloc_saved_regs): Initialize via a
constructor and reset the state of the registers.
(trad_frame_value_p, trad_frame_addr_p, trad_frame_realreg_p)
(trad_frame_value_bytes_p, trad_frame_set_value)
(trad_frame_set_realreg, trad_frame_set_addr)
(trad_frame_set_unknown, trad_frame_set_value_bytes): Remove.
(trad_frame_set_reg_realreg): Update to call member function.
(trad_frame_set_reg_addr, trad_frame_set_reg_value_bytes): Likewise.
(trad_frame_get_prev_register): Likewise.

* aarch64-tdep.c (aarch64_analyze_prologue)
(aarch64_analyze_prologue_test, aarch64_make_prologue_cache_1)
(aarch64_prologue_prev_register): Update to use member functions.
* alpha-mdebug-tdep.c (alpha_mdebug_frame_unwind_cache): Likewise.
* alpha-tdep.c (alpha_heuristic_frame_unwind_cache): Likewise.
* arc-tdep.c (arc_print_frame_cache, arc_make_frame_cache): Likewise.
* arm-tdep.c (arm_make_prologue_cache, arm_exidx_fill_cache)
(arm_make_epilogue_frame_cache): Likewise.
* avr-tdep.c (avr_frame_unwind_cache)
(avr_frame_prev_register): Likewise.
* cris-tdep.c (cris_scan_prologue): Likewise.
* csky-tdep.c (csky_frame_unwind_cache): Likewise.
* frv-tdep.c (frv_analyze_prologue): Likewise.
* hppa-tdep.c (hppa_frame_cache, hppa_fallback_frame_cache): Likewise.
* lm32-tdep.c (lm32_frame_cache): Likewise.
* m32r-tdep.c (m32r_frame_unwind_cache): Likewise.
* m68hc11-tdep.c (m68hc11_frame_unwind_cache): Likewise.
* mips-tdep.c (set_reg_offset, mips_insn16_frame_cache)
(mips_micro_frame_cache, mips_insn32_frame_cache): Likewise.
(reset_saved_regs): Adjust to set realreg.
* riscv-tdep.c (riscv_scan_prologue, riscv_frame_cache): Adjust to
call member functions.
* rs6000-tdep.c (rs6000_frame_cache, rs6000_epilogue_frame_cache)
* s390-tdep.c (s390_prologue_frame_unwind_cache)
(s390_backchain_frame_unwind_cache): Likewise.
* score-tdep.c (score7_analyze_prologue)
(score3_analyze_prologue, score_make_prologue_cache): Likewise.
* sparc-netbsd-tdep.c (sparc32nbsd_sigcontext_saved_regs): Likewise.
* sparc-sol2-tdep.c (sparc32_sol2_sigtramp_frame_cache): Likewise.
* sparc64-netbsd-tdep.c (sparc64nbsd_sigcontext_saved_regs): Likewise.
* sparc64-sol2-tdep.c (sparc64_sol2_sigtramp_frame_cache): Likewise.
* tilegx-tdep.c (tilegx_analyze_prologue)
(tilegx_frame_cache): Likewise.
* v850-tdep.c (v850_frame_cache): Likewise.
* vax-tdep.c (vax_frame_cache): Likewise.

Convert some frame functions to use gdb::array_view.

This patch converts the most obvious functions from gdb/frame.h to use
the gdb::array_view abstraction.  I've converted the ones that used buffer +
length.

There are others using only the buffer, with an implicit size. I did not
touch those for now. But it would be nice to pass the size for safety.

Tested with --enable-targets=all on Ubuntu 18.04/20.04 aarch64-linux.

gdb/ChangeLog

2021-01-19  Luis Machado  <luis.machado@linaro.org>

* frame.h (get_frame_register_bytes): Pass a gdb::array_view instead
of buffer + length.
(put_frame_register_bytes): Likewise.
Adjust documentation.
(get_frame_memory): Pass a gdb::array_view instead of buffer + length.
(safe_frame_unwind_memory): Likewise.
* frame.c (get_frame_register_bytes, put_frame_register_bytes)
(get_frame_memory, safe_frame_unwind_memory): Adjust to use
gdb::array_view.
* amd64-fbsd-tdep.c (amd64fbsd_sigtramp_p): Likewise.
* amd64-linux-tdep.c (amd64_linux_sigtramp_start): Likewise.
* amd64-obsd-tdep.c (amd64obsd_sigtramp_p): Likewise.
* arc-linux-tdep.c (arc_linux_is_sigtramp): Likewise.
* cris-tdep.c (cris_sigtramp_start, cris_rt_sigtramp_start): Likewise.
* dwarf2/loc.c (rw_pieced_value): Likewise.
* hppa-tdep.c (hppa_frame_cache): Likewise.
* i386-fbsd-tdep.c (i386fbsd_sigtramp_p): Likewise.
* i386-gnu-tdep.c (i386_gnu_sigtramp_start): Likewise.
* i386-linux-tdep.c (i386_linux_sigtramp_start)
(i386_linux_rt_sigtramp_start): Likewise.
* i386-obsd-tdep.c (i386obsd_sigtramp_p): Likewise.
* i386-tdep.c (i386_register_to_value): Likewise.
* i387-tdep.c (i387_register_to_value): Likewise.
* ia64-tdep.c (ia64_register_to_value): Likewise.
* m32r-linux-tdep.c (m32r_linux_sigtramp_start)
(m32r_linux_rt_sigtramp_start): Likewise.
* m68k-linux-tdep.c (m68k_linux_pc_in_sigtramp): Likewise.
* m68k-tdep.c (m68k_register_to_value): Likewise.
* mips-tdep.c (mips_register_to_value)
(mips_value_to_register): Likewise.
* ppc-fbsd-tdep.c (ppcfbsd_sigtramp_frame_sniffer)
(ppcfbsd_sigtramp_frame_cache): Likewise.
* ppc-obsd-tdep.c (ppcobsd_sigtramp_frame_sniffer)
(ppcobsd_sigtramp_frame_cache): Likewise.
* rs6000-tdep.c (rs6000_in_function_epilogue_frame_p)
(rs6000_register_to_value): Likewise.
* tilegx-tdep.c (tilegx_analyze_prologue): Likewise.
* tramp-frame.c (tramp_frame_start): Likewise.
* valops.c (value_assign): Likewise.

sim: ppc: update version script usage

This matches the changes in the common code.

Use gdb::array_view for setting value bytes in trad-frame

This patch updates the functions setting value bytes in trad-frame to use
a gdb::array_view instead of passing a buffer and a size.

gdb/ChangeLog:

2021-01-19  Luis Machado  <luis.machado@linaro.org>

* aarch64-linux-tdep.c (aarch64_linux_restore_vreg): Pass in an
array_view.
* trad-frame.c (trad_frame_set_value_bytes): Use gdb::array_view
instead of buffer and size.
(trad_frame_set_reg_value_bytes): Likewise.
* trad-frame.h (trad_frame_set_reg_value_bytes): Likewise.
(trad_frame_set_value_bytes): Likewise.

libctf, create: fix ctf_type_add of structs with unnamed members

Our recent commit to support unnamed structure members better ditched
the old ctf_member_iter iterator body in favour of ctf_member_next.
However, these functions treat unnamed structure members differently:
ctf_member_iter just returned whatever the internal representation
contained, while ctf_member_next took care to always return "" rather
than sometimes returning "" and sometimes NULL depending on whether the
dict was dynamic (a product of ctf_create) or not (a product of
ctf_open).  After this commit, ctf_member_iter did the same.

It was always a bug for external callers not to treat a "" return from
these functions as if it were NULL, so only buggy callers could be
affected -- but one of those buggy callers was ctf_add_type, which
assumed that it could just take whatever name was returned from
ctf_member_iter and slam it directly into the internal representation of
a dynamic dict -- which expects NULL for unnamed members, not "".  The
net effect of all of this is that taking a struct containing unnamed
members and ctf_add_type'ing it into a dynamic dict produced a dict
whose unnamed members were inaccessible to ctf_member_info (though if
you wrote that dict out and then ctf_open'ed it, they would magically
reappear again).

Compensate for this by suitably transforming a "" name into NULL in the
internal representation, as should have been done all along.

libctf/ChangeLog
2021-01-19  Nick Alcock  <nick.alcock@oracle.com>

* ctf-create.c (membadd): Transform ""-named members into
NULL-named ones.
* testsuite/libctf-regression/type-add-unnamed-struct*: New test.

libctf: lookup_by_name: do not return success for nonexistent pointer types

The recent work allowing lookups of pointers in child dicts when the
pointed-to type is in the parent dict broke the case where a pointer
type that does not exist at all is looked up: we mistakenly return the
pointed-to type, which is likely not a pointer at all.  This causes
considerable confusion.

Fixed, with a new testcase.

libctf/ChangeLog
2021-01-19  Nick Alcock  <nick.alcock@oracle.com>

* ctf-lookup.c (ctf_lookup_by_name_internal): Do not return the
base type if looking up a nonexistent pointer type.
* testsuite/libctf-regression/pptrtab*: Test it.

libctf, ld: fix data symbol test with newer GCC

GCC 11+ spots that the extern var_1 and var_666 declarations in this
test are unused, and removes them, thus stopping them from appearing as
conflicted data symbols and rendering the test pointless.  Use them in a
function unique to this TU to prevent them from being eliminated.

ld/ChangeLog
2021-01-19  Nick Alcock  <nick.alcock@oracle.com>

* testsuite/ld-ctf/data-func-2.c: Stop removal of the extern foo_t
symbols by the optimizer.
* testsuite/ld-ctf/data-func-conflicted.d: Adjust accordingly.

[gdb/testsuite] Fix gdb.base/step-over-syscall.exp with -m32

When executing test-case gdb.base/step-over-syscall.exp with target board
unix/-m32, we run into:
...
(gdb) x/2i $pc^M
=> 0xf7fd5155 <__kernel_vsyscall+5>:    sysenter ^M
   0xf7fd5157 <__kernel_vsyscall+7>:    int    $0x80^M
(gdb) PASS: gdb.base/step-over-syscall.exp: fork: displaced=off: \
  pc before/after syscall instruction
stepi^M
[Detaching after fork from child process 23593]^M
0xf7fd5159 in __kernel_vsyscall ()^M
1: x/i $pc^M
=> 0xf7fd5159 <__kernel_vsyscall+9>:    pop    %ebp^M
(gdb) PASS: gdb.base/step-over-syscall.exp: fork: displaced=off: stepi fork insn
print /x $pc^M
$2 = 0xf7fd5159^M
(gdb) PASS: gdb.base/step-over-syscall.exp: fork: displaced=off: pc after stepi
FAIL: gdb.base/step-over-syscall.exp: fork: displaced=off: \
  pc after stepi matches insn addr after syscall
...

The test tries to verify that after doing a stepi at a syscall insn, the $pc
is matching the insn after the syscall insn.

However, in the case that the syscall insn is "sysenter", the stepi will land
further away, so in this case:
...
   0xf7fd5155 <__kernel_vsyscall+5>:    sysenter ^M
   0xf7fd5157 <__kernel_vsyscall+7>:    int    $0x80^M
   0xf7fd5159 <__kernel_vsyscall+9>:    pop    %ebp^M
...
the stepi will land at 0xf7fd5159 instead of 0xf7fd5157.

Fix this by detecting the sysenter/int sequence and adjusting the expected
pc.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-01-19  Tom de Vries  <tdevries@suse.de>

* gdb.base/step-over-syscall.exp: Detect and handle sysenter/int
sequence.

[gdb/testsuite] Fix gdb.arch/i386-mpx.exp with -m32

When running test-case gdb.arch/i386-mpx.exp with target board unix/-m32, we
run into:
...
(gdb) print $bndstatus^M
$3 = {raw = 0xf7ca7ff2, status = {bde = 1039310844, error = 2}}^M
(gdb) FAIL: gdb.arch/i386-mpx.exp: bndstatus formating
print $bndstatus.raw^M
$4 = (void *) 0xf7ca7ff2^M
(gdb) FAIL: gdb.arch/i386-mpx.exp: bndstatus is zero by startup
...

The failure does not occur with -m64, there we have instead:
...
(gdb) print $bndstatus^M
$3 = {raw = 0x0, status = {bde = 0, error = 0}}^M
(gdb) PASS: gdb.arch/i386-mpx.exp: bndstatus formating
print $bndstatus.raw^M
$4 = (void *) 0x0^M
(gdb) PASS: gdb.arch/i386-mpx.exp: bndstatus is zero by startup
...

The difference is as follows.  At the point of issuing the print commands, we
have run to main, so in the case of -m64 we have executed:
...
00000000004004c7 <main>:
  4004c7:       55                      push   %rbp
  4004c8:       48 89 e5                mov    %rsp,%rbp
  4004cb:       89 7d fc                mov    %edi,-0x4(%rbp)
  4004ce:       48 89 75 f0             mov    %rsi,-0x10(%rbp)
  4004d2:       66 0f 1b 45 e0          bndmov %bnd0,-0x20(%rbp)
...
and in the case of -m32:
...
08048426 <main>:
 8048426:       55                      push   %ebp
 8048427:       89 e5                   mov    %esp,%ebp
 8048429:       83 ec 08                sub    $0x8,%esp
 804842c:       8d 45 0c                lea    0xc(%ebp),%eax
 804842f:       8b 55 0c                mov    0xc(%ebp),%edx
 8048432:       0f 1a 04 10             bndldx (%eax,%edx,1),%bnd0
 8048436:       66 0f 1b 45 f8          bndmov %bnd0,-0x8(%ebp)
...

In both cases, the bnd instructions attempt to save the bound for pointer
argument argv to stack.  However, there's no such bound set.

In the -m64 case, that means we just save some random value to stack.

In the -m32 case, that means that when executing bndldx the corresponding
entry in the Bounds Directory is invalid, and $bndstatus is updated to reflect
that.

Fix this by dropping the unnecessary argv parameter to main, similar to all
other gdb.arch/i386-mpx*.c test-cases.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-01-19  Tom de Vries  <tdevries@suse.de>

* gdb.arch/i386-mpx.c (main): Drop argc/argv parameter.

PowerPC use_local_plt

Put the logic to select local vs. usual .plt section in one place.

* elf64-ppc.c (elf_hash_entry): New inline function.  Use
throughout to replace casts.
(branch_reloc_hash_match): Remove const from params.
(use_local_plt): New function.
(allocate_dynrelocs, ppc_build_one_stub, ppc_size_one_stub),
(build_global_entry_stubs_and_plt, ppc64_elf_relocate_section):
Use use_local_plt.
* elf32-ppc.c (use_local_plt): New function.
(allocate_dynrelocs, ppc_elf_relocate_section),
(write_global_sym_plt): Use use_local_plt.

[GOLD] powerpc assertion failure

A testcase with only ifuncs can result in no plt section (ifunc plt
entries might instead be in iplt), which means we can get to this code
without a static link.

PR 27203
* powerpc.cc (do_plt_fde_location): Remove doing_static_link
assertion.

sim: bfin: delete accidental ADI copyright

This wasn't supposed to be in here when it was first merged as we
had specifically disabled it for all the tests (and ADI has papers
in place w/the FSF).  Clean up this one.

ld: Just xfail riscv little endian targets for compressed1d.d test.

The sizes of compressed and uncompressed .debug_aranges are the same
for the riscv big endian targets, but different for the little endian
targets.  The compress rule is fine and isn't broken by riscv, just the
original compressed1d.d fails by accident.  Ideally, we should fill the
R_RISCV_ADD/SUB relocations when disabling relaxations in the assembler.
But before that, Jim already had written an alternative test compressed1d-alt
to relpace compressed1d.d for riscv, so we can only xfail the riscv little
endian targets in the short-term.

ld/
    * testsuite/ld-elf/elf.exp (riscv_little_endian): Added.  Return true
    if target is riscv little endian.  Otherwise, return false.
    * testsuite/ld-elf/compressed1d.d: Only xfail the riscv little endian
    targets by [riscv_little_endian].

Automatic date update in version.in

sim: common: simplify version script

We don't use the host & target aliases, so don't bother emitting them.

sim: common: delete configure & Makefile

This was mostly orphaned a while back, but left behind so people could
still run `make headers`.  Merge that one target to the top sim dir and
delete all the build logic.  This should avoid confusing people further.

sim: common: modernize gennltvals.sh

It's not 1996 anymore, so stop writing shell code like it is, and
rewrite it with modern POSIX shell standards.  This makes it much
more user friendly.

Then regenerate the file with latest newlib sources to verify.

gdb/testsuite: remove actual addresses from some test names

After commit:

  commit 10f92414d6d4a5f8eb8cbb2bf39ca86c1f9c1da5
  Date:   Fri Jan 15 12:14:45 2021 +0100

      [gdb/testsuite] Fix gdb.fortran/array-slices.exp with -m32

Some test names now contain the addresses of variables from the
inferior.  When running the test in different directories I'm seeing
slightly different values for the addresses.  This makes comparing
test results between directories harder than it needs to be.

This commit just gives the tests a descriptive name without including
the addresses.

gdb/testsuite/ChangeLog:

* gdb.fortran/array-slices.exp (run_test): Avoid including
addresses in test names.

as: Automatically enable DWARF5 support

Currently

$ as -o x.o x.s

fails when x.s contains DWARF5 ".file 0" or ".loc 0" directives.  Update
assembler to automatically enable DWARF5 support so that

$ gcc -S -g -c x.c
$ gcc -c x.s

works.

PR gas/27195
* dwarf2dbg.c (dwarf2_gen_line_info): Set dwarf_level to 5 if
needed.
(dwarf2_directive_filename): Likewise.
(dwarf2_directive_loc): Likewise.
* testsuite/gas/elf/dwarf-5-file0.d: Pass --gdwarf-3.
* testsuite/gas/lns/lns-diag-1.l: Remove the
"Error: file number less than one" errors.

gdb/riscv: use a single regset supply function for riscv fbsd & linux

The RISC-V x0 register is hard-coded to zero.  As such neither Linux
or FreeBSD supply the value of the register x0 in their core dump
files.

For FreeBSD we take care of this by manually supplying the value of x0
in riscv_fbsd_supply_gregset, however we don't do this for Linux.  As
a result after loading a core file on Linux we see this behaviour:

  (gdb) p $x0
  $1 = <unavailable>

In this commit I make riscv_fbsd_supply_gregset a common function that
can be shared between RISC-V for FreeBSD and Linux, this resolves the
above issue.

There is a similar problem for the two registers `fflags` and `frm`.
These two floating point related CSRs are a little weird.  They are
separate CSRs in the RISC-V specification, but are actually sub-fields
of the `fcsr` CSR.

As a result neither Linux or FreeBSD supply the `fflags` or `frm`
registers as separate fields in their core dumps, and so, after
restoring a core dump these register are similarly unavailable.

In this commit I supply `fflags` and `frm` by first asking for the
value of `fcsr`, extracting the two fields, and using these to supply
the values for `fflags` and `frm`.

gdb/ChangeLog:

* riscv-fbsd-tdep.c (riscv_fbsd_supply_gregset): Delete.
(riscv_fbsd_gregset): Use riscv_supply_regset.
(riscv_fbsd_fpregset): Likewise.
* riscv-linux-tdep.c (riscv_linux_gregset): Likewise.
(riscv_linux_fregset): Likewise.
* riscv-tdep.c (riscv_supply_regset): Define new function.
* riscv-tdep.h (riscv_supply_regset): Declare new function.

PR26378, sections initialised only by linker scripts are always read/write

This changes the initialisation of output sections so that it is
possible to create read-only sections fed only from linker script
BYTE, SHORT, LONG or QUAD.  That currently isn't possible even for one
of the well-known ELF sections like .rodata, because once a section is
marked read/write that sticks.  On the other hand if we start
read-only, well-known ELF sections end up read/write as appropriate.
For example .tdata will still be SHF_ALLOC + SHF_WRITE + SHF_TLS.

PR 26378
* ldlang.c (map_input_to_output_sections): Start with a read-only
section for data statements.
* testsuite/ld-elf/size-2.d: Adjust to suit.

[gdb/tdep] Handle si_addr_bnd in compat_siginfo_from_siginfo

When running test-case gdb.arch/i386-mpx-sigsegv.exp with target board
unix/-m32, we run into:
...
(gdb) continue^M
Continuing.^M
Saw a #BR! status 1 at 0x8048c2d^M
^M
Program received signal SIGSEGV, Segmentation fault^M
Upper bound violation while accessing address 0x0804c15c^M
Bounds: [lower = 0x00000000, upper = 0x00000000].^M
0x08048a4f in lower (p=0x804c160, a=0x804c180, b=0x804c1a0, c=0x804c1c0, \
  d=0x804c1e0, len=1) at i386-mpx-sigsegv.c:79^M
79        value = *(p - len);^M
(gdb) FAIL: gdb.arch/i386-mpx-sigsegv.exp: MPX signal segv Lower: 0
...

The problem is that lower and upper in the Bounds message are 0x0, which is
caused by $_siginfo._sifields._sigfault._addr_bnd.{_lower,_upper} evaluating
to 0x0.

Fix this by copying the si_lower/si_upper fields in
compat_siginfo_from_siginfo.

Tested on x86_64-linux, with target board unix/-m32.

gdb/ChangeLog:

2021-01-18  Tom de Vries  <tdevries@suse.de>

PR tdep/27172
* nat/amd64-linux-siginfo.c (cpt_si_lower, cpt_si_upper, SEGV_BNDERR):
New macro.
(compat_siginfo_from_siginfo): Copy cpt_si_lower and cpt_si_upper
for SEGV_BNDERR.

gdb: const-ify hostio methods parameter in remote.c

gdb/ChangeLog:

* remote.c (class remote_target) <remote_hostio_send_command,
remote_hostio_parse_result>: Constify parameter.
(remote_hostio_parse_result): Likewise.
(remote_target::remote_hostio_send_command): Adjust.
(remote_target::remote_hostio_pread_vFile): Adjust.
(remote_target::fileio_readlink): Adjust.
(remote_target::fileio_fstat): Adjust.

Change-Id: I6b585b99937e6526a0a7e06261d2193114589912

gdb: move remote_target::start_remote variable to narrower scope

The wait_status variable is only used when the target is in in all-stop
mode.  We can therefore move it in the !target_is_non_stop scope.  That
lets us remove the assert in the else, that checks that the wait status
is not set.  If the variable doesn't exist in that scope, it pretty much
guarantees that it is not set.

gdb/ChangeLog:

* remote.c (remote_target::start_remote): Move wait_status to
narrower scope.

Change-Id: I30979135e3f4f36d04178baa67575c4e58d3b648

gdb: const-ify remote_target::add_current_inferior_and_thread parameter

... and adjust callers / callees.

gdb/ChangeLog:

* remote.c (class remote_target):
<add_current_inferior_and_thread>: Constify parameter.
(stop_reply_extract_thread): Likewise.
(remote_target::get_current_thread): Likewise.
(remote_target::add_current_inferior_and_thread): Likewise.

Change-Id: Ifdc6c263104b58852b532cfda81caf836437d29c

gdb: const-ify unpack_* functions in remote.c

Const-ify the unpack_* functions, and then adjust the callers
accordingly.

gdb/ChangeLog:

* remote.c (class remote_target)
<remote_unpack_thread_info_response,
parse_threadlist_response>: Constify parameter and/or return
value and or local variable.
(stub_unpack_int): Likewise.
(unpack_nibble): Likewise.
(unpack_byte): Likewise.
(unpack_int): Likewise.
(unpack_string): Likewise.
(unpack_threadid): Likewise.
(remote_target::remote_unpack_thread_info_response): Likewise.
(remote_target::parse_threadlist_response): Likewise.

Change-Id: Ibda75f664d6e3452df00f85af7134533049171b7

PR27198, segv in S_IS_WEAK

Fix a NULL dereference seen when assembling invalid input.

PR 27198
* config/tc-i386.c (need_plt32_p): Return FALSE for NULL symbol.
* testsuite/gas/i386/pr27198.d,
* gas/testsuite/gas/i386/pr27198.err,
* gas/testsuite/gas/i386/pr27198.s: New test.
* gas/testsuite/gas/i386/i386.exp: Run it.

ld/elf: Ignore section symbols when matching linkonce with comdat

When deciding if a single member comdat group section in file FOO should
be discarded by a linkonce section in file BAR, we check if 2 sections
define the same set of local and global symbols.  When only one of the
files doesn't contain the unused section symbols in the symbol table,
such as object files generated by clang or GNU assembler with

commit d1bcae833b32f1408485ce69f844dcd7ded093a8
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Thu Jan 7 06:42:00 2021 -0800

    ELF: Don't generate unused section symbols

the check will fail since one file has the extra unused section symbols.
We should ignore both undefined and section symbols in the symbol table
when making such a decision.

bfd/

PR ld/27193
* elflink.c (elf_create_symbuf): Also ignore section symbols.

ld/

PR ld/27193
* testsuite/ld-i386/i386.exp: Run PR ld/27193 test.
* testsuite/ld-i386/pr27193.dd: New file.
* testsuite/ld-i386/pr27193a.o.bz2: Likewise.
* testsuite/ld-i386/pr27193b.s: Likewise.

gold: Remove the circular IFUNC dependency in ifuncmain6pie

On Fedora 33 x86-64 with glibc 2.32-3, ifuncmain6pie failed with:

./ifuncmain6pie: IFUNC symbol 'foo' referenced in './ifuncmod6.so' is defined in the executable and creates an unsatisfiable circular dependency.
FAIL ifuncmain6pie (exit status: 127)

Remove non-JUMP_SLOT relocations against foo in ifuncmod6.so, which
trigger the circular IFUNC dependency.

* testsuite/ifuncmain6pie.c: Remove non-JUMP_SLOT relocations
against foo in ifuncmod6.so.
* testsuite/ifuncmod6.c: Likewise.

Automatic date update in version.in

PR binutils/23460: Increase the max number of open files to 20

Increase the max number of open files to 20 for PR binutils/23460 test
which may have more than 16 file descriptors open:

lr-x------ 1 hjl hjl 64 Jan 16 16:49 0 -> /dev/null
l-wx------ 1 hjl hjl 64 Jan 16 16:49 1 -> pipe:[14151430]
lr-x------ 1 hjl hjl 64 Jan 16 16:49 10 -> /export/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux/binutils/src/binutils-build/ld/tmpdir/pr23460c.o
lr-x------ 1 hjl hjl 64 Jan 16 16:49 11 -> /export/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux/binutils/src/binutils-build/ld/tmpdir/pr23460d.o
lr-x------ 1 hjl hjl 64 Jan 16 16:49 12 -> /export/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux/binutils/src/binutils-build/ld/tmpdir/pr23460e.o
lr-x------ 1 hjl hjl 64 Jan 16 16:49 13 -> /export/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux/binutils/src/binutils-build/ld/tmpdir/pr23460f.o
lrwx------ 1 hjl hjl 64 Jan 16 16:49 14 -> /export/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux/binutils/src/binutils-build/ld/tmpdir/stTLiXpO
lrwx------ 1 hjl hjl 64 Jan 16 16:49 15 -> /export/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux/binutils/src/binutils-build/ld/tmpdir/stTLiXpO
l-wx------ 1 hjl hjl 64 Jan 16 16:49 2 -> pipe:[14151430]
lr-x------ 1 hjl hjl 64 Jan 16 16:49 3 -> pipe:[13933216]
l-wx------ 1 hjl hjl 64 Jan 16 16:49 4 -> pipe:[13933216]
lr-x------ 1 hjl hjl 64 Jan 16 16:49 5 -> pipe:[13990857]
l-wx------ 1 hjl hjl 64 Jan 16 16:49 6 -> pipe:[13990857]
lr-x------ 1 hjl hjl 64 Jan 16 16:49 7 -> /export/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux/binutils/src/binutils-build/ld/tmpdir/libpr23460.a
lr-x------ 1 hjl hjl 64 Jan 16 16:49 8 -> /export/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux/binutils/src/binutils-build/ld/tmpdir/pr23460a.o
lr-x------ 1 hjl hjl 64 Jan 16 16:49 9 -> /export/build/gnu/tools-build/x86_64-linux-toolchain/build-x86_64-linux/binutils/src/binutils-build/ld/tmpdir/pr23460b.o

PR binutils/23460
* testsuite/ld-plugin/lto.exp: Increase the max number of open
files to 20 for PR binutils/23460 test.