gdb/dwarf: split dwarf2_cu::ranges_base in two

Consider the test case added in this patch.  It defines a compilation
unit with a DW_AT_rnglists_base attribute (used for attributes of form
DW_FORM_rnglistx), but also uses DW_AT_ranges of form
DW_FORM_sec_offset:

    0x00000027: DW_TAG_compile_unit
                  DW_AT_ranges [DW_FORM_sec_offset] (0x0000004c
                     [0x0000000000005000, 0x0000000000006000))
                  DW_AT_rnglists_base [DW_FORM_sec_offset]  (0x00000044)

The DW_AT_rnglists_base does not play a role in reading the DW_AT_ranges of
form DW_FORM_sec_offset, but it should also not do any harm.

This case is currently not handled correctly by GDB.  This is not
something that a compiler is likely to emit, but in my opinion there's
no reason why GDB should fail reading it.

The problem is that in partial_die_info::read and a few other places
where the same logic is replicated, the cu->ranges_base value,
containing the DW_AT_rnglists_base value, is wrongfully added to the
DW_AT_ranges value.

It is quite messy how to decide whether cu->ranges_base should be added
to the attribute's value or not.  But to summarize, the only time we
want to add it is when the attribute comes from a pre-DWARF 5 split unit
file (a .dwo) [1].  In this case, the DW_AT_ranges attribute from the
split unit file will have form DW_FORM_sec_offset, pointing somewhere in
the linked file's .debug_ranges section.  *But* it's not a "true"
DW_FORM_sec_offset, in that it's an offset relative to the beginning of
that CU's contribution in the section, not relative to the beginning of
the section.  So in that case, and only that case, do we want to add the
ranges base value, which we found from the DW_AT_GNU_ranges_base
attribute on the skeleton unit.

Almost all instances of the DW_AT_ranges attribute will be found in the
split unit (on DW_TAG_subprogram, for example), and therefore need to
have the ranges base added.  However, the DW_TAG_compile_unit DIE in the
skeleton may also have a DW_AT_ranges attribute.  For that one, the
ranges base must not be added.  Once the DIEs have been loaded in GDB,
however, the distinction between what's coming from the skeleton and
what's coming from the split unit is not clear.  It is all merged in one
big happy tree.  So how do we know if a given attribute comes from the
split unit or not?

We use the fact that in pre-DWARF 5 split DWARF, DW_AT_ranges is found
on the skeleton's DW_TAG_compile_unit (in the linked file) and never in
the split unit's DW_TAG_compile_unit.  This is why you have this in
partial_die_info::read:

      int need_ranges_base = (tag != DW_TAG_compile_unit
      && attr.form != DW_FORM_rnglistx);

However, with the corner case described above (where we have a
DW_AT_rnglists_base attribute and a DW_AT_ranges attribute of form
DW_FORM_sec_offset) the condition gets it wrong when it encounters an
attribute like DW_TAG_subprogram with a DW_AT_ranges attribute of
DW_FORM_sec_offset form: it thinks that it is necessary to add the base,
when it reality it is not.

The problem boils down to failing to differentiate these cases:

  - a DW_AT_ranges attribute of form DW_FORM_sec_offset in a
    pre-DWARF 5 split unit (in which case we need to add the base)
  - a DW_AT_ranges attribute of form DW_FORM_sec_offset in a DWARF 5
    non-split unit (in which case we must not add the base)

What makes it unnecessarily complex is that the cu->ranges_base field is
overloaded, used to hold the pre-DWARF 5, non-standard
DW_AT_GNU_ranges_base and the DWARF 5 DW_AT_rnglists_base.  In reality,
these two are called "bases" but are not the same thing.  The result is
that we need twisted conditions to try to determine whether or not we
should add the base to the attribute's value.

To fix it, split the field in two distinct fields.  I renamed everything
related to the "old" ranges base to "gnu_ranges_base", to make it clear
that it's about the non-standard, pre-DWARF 5 thing.  And everything
related to the DWARF 5 thing gets renamed "rnglists".  I think it
becomes much easier to reason this way.

The issue described above gets fixed by the fact that the
DW_AT_rnglists_base value does not end up in cu->gnu_ranges_base, so
cu->gnu_ranges_base stays 0.  The condition to determine whether
gnu_ranges_base should be added can therefore be simplified back to:

  tag != DW_TAG_compile_unit

... as it was before rnglistx support was added.

Extend the gdb.dwarf2/rnglists-sec-offset.exp to cover this case.  I
also extended the test case for loclists similarly, just to see if there
would be some similar problem.  There wasn't, but I think it's not a bad
idea to test that case for loclists as well, so I left it in the patch.

[1] https://gcc.gnu.org/wiki/DebugFission

gdb/ChangeLog:

* dwarf2/die.h (struct die_info) <ranges_base>: Split in...
<gnu_ranges_base>: ... this...
<rnglists_base>: ... and this.
* dwarf2/read.c (struct dwarf2_cu) <ranges_base>: Split in...
<gnu_ranges_base>: ... this...
<rnglists_base>: ... and this.
(read_cutu_die_from_dwo): Adjust
(dwarf2_get_pc_bounds): Adjust
(dwarf2_record_block_ranges): Adjust.
(read_full_die_1): Adjust
(partial_die_info::read): Adjust.
(read_rnglist_index): Adjust.

gdb/testsuite/ChangeLog:

* gdb.dwarf2/rnglists-sec-offset.exp: Add test for DW_AT_ranges
of DW_FORM_sec_offset form plus DW_AT_rnglists_base attribute.
* gdb.dwarf2/loclists-sec-offset.exp: Add test for
DW_AT_location of DW_FORM_sec_offset plus DW_AT_loclists_base
attribute

Change-Id: Icd109038634b75d0e6e9d7d1dcb62fb9eb951d83

gdb/testsuite: add .debug_loclists tests

Add tests for the various issues fixed in the previous patches.

Add a new "loclists" procedure to the DWARF assembler, to allow
generating .debug_loclists sections.

gdb/testsuite/ChangeLog:

PR gdb/26813
* lib/dwarf.exp (_handle_DW_FORM): Handle DW_FORM_loclistx.
(loclists): New proc.
* gdb.dwarf2/loclists-multiple-cus.c: New.
* gdb.dwarf2/loclists-multiple-cus.exp: New.
* gdb.dwarf2/loclists-sec-offset.c: New.
* gdb.dwarf2/loclists-sec-offset.exp: New.

Change-Id: I209bcb2a9482762ae943e518998d1f7761f76928

gdb/testsuite: DWARF assembler: add context parameters to _location

The _location proc is used to assemble a location description.  It needs
to know some contextual information:

- size of an address
- size of an offset (into another DWARF section)
- DWARF version

It currently get all this directly from global variables holding the
compilation unit information.  This is fine because as of now, all
location descriptions are generated in the context of creating a
compilation unit.  However, a subsequent patch will generate location
descriptions while generating a .debug_loclists section.  _location
should therefore no longer rely on the current compilation unit's
properties.

Change it to accept these values as parameters instead of accessing the
values for the CU.

No functional changes intended.

gdb/testsuite/ChangeLog:

* lib/dwarf.exp (_location): Add parameters.
(_handle_DW_FORM): Adjust.

Change-Id: Ib94981979c83ffbebac838081d645ad71c221637

gdb/testsuite: add .debug_rnglists tests

Add tests for the various issues fixed in the previous patches.

Add a new "rnglists" procedure to the DWARF assembler, to allow
generating .debug_rnglists sections.  A trivial change is required to
support the DWARF 5 CU header layout.

gdb/testsuite/ChangeLog:

PR gdb/26813
* lib/dwarf.exp (_handle_DW_FORM): Handle DW_FORM_rnglistx.
(cu): Generate header for DWARF 5.
(rnglists): New proc.
* gdb.dwarf2/rnglists-multiple-cus.exp: New.
* gdb.dwarf2/rnglists-sec-offset.exp: New.

Change-Id: I5b297e59c370c60cf671dec19796a6c3b9a9f632

gdb/dwarf: read correct rnglist/loclist header in read_{rng,loc}list_index

When loading the binary from PR 26813 in GDB, we get:

    DW_FORM_rnglistx index pointing outside of .debug_rnglists offset array [in module /home/simark/build/binutils-gdb/gdb/MagicPurse]

... and the symbols fail to load.

In read_rnglist_index and read_loclist_index, we read the header
(documented in sections 7.28 and 7.29 of DWARF 5) of the CU's
contribution to the .debug_rnglists / .debug_loclists sections to
validate that the index we want to read makes sense.  However, we always
read the header at the beginning of the section, rather than the header
for the contribution from which we want to read the index.

To illustrate, here's what the binary from PR 26813 contains.  There are
two compile units:

0x0000000c: DW_TAG_compile_unit 1
              DW_AT_ranges [DW_FORM_rnglistx]: 0x0
              DW_AT_rnglists_base [DW_FORM_sec_offset]: 0xC

0x00003ec9: DW_TAG_compile_unit 2
              DW_AT_ranges [DW_FORM_rnglistx]: 0xB
              DW_AT_rnglists_base [DW_FORM_sec_offset]: 0x85

The layout of the .debug_rnglists is the following:

    [0x00, 0x0B]: header for CU 1's contribution
    [0x0C, 0x0F]: list of offsets for CU 1 (1 element)
    [0x10, 0x78]: range lists data for CU 1

    [0x79, 0x84]: header for CU 2's contribution
    [0x85, 0xB4]: list of offsets for CU 2 (12 elements)
    [0xB5, 0xBD7]: range lists data for CU 2

The DW_AT_rnglists_base attrbute points to the beginning of the list of
offsets for that CU, relative to the start of the .debug_rnglists
section.  That's right after the header for that contribution.

When we try to read the DW_AT_ranges attribute for CU 2,
read_rnglist_index reads the header for CU 1 instead of the one for CU
2.  Since there's only one element in CU 1's offset list, it believes
(wrongfully) that the index 0xB is out of range.

Fix it by reading the header just before where DW_AT_rnglists_base
points to.  With this patch, I am able to load GDB built with clang-11
and -gdwarf-5 in itself, with and without -readnow.

gdb/ChangeLog:

PR gdb/26813
* dwarf2/read.c (read_loclists_rnglists_header): Add
header_offset parameter and use it.
(read_loclist_index): Read header of the current contribution,
not the one at the beginning of the section.
(read_rnglist_index): Likewise.

Change-Id: Ie53ff8251af8c1556f0a83a31aa8572044b79e3d

gdb/dwarf: few fixes for handling DW_FORM_{rng,loc}listx

We hit an assertion when loading the binary from PR 26813.  When fixing
it, execution goes a up bit further but then hits another assert, and
another, and another.  With these fours fixes, I am able to load the
binary and get to the prompt.  An error is shown (index pointing outside
of the section), because the DW_FORM_rnglistx attribute is not read
correctly, but that one is taken care of by the next patch.

The four fixes are:

- attribute::form_requires_reprocessing needs to handle forms
  DW_FORM_rnglistx and DW_FORM_loclistx, because set_unsigned_reprocess
  is called for them in read_attribute_value.

- read_attribute_reprocess must call set_unsigned for them, not
  set_address.  The parameter of set_address is a CORE_ADDR, meaning
  it's for program addresses.  Post-reprocess, DW_FORM_rnglistx and
  DW_FORM_loclistx are offsets into their respective sections
  (.debug_rnglists and .debug_loclists).  set_unsigned is the current
  attribute value setter that fits the best.  But perhaps we should have
  a setter that takes a sect_offset?

- read_attribute_process must call as_unsigned_reprocess instead of
  as_unsigned to get the pre-reprocess value, otherwise we hit the
  assert inside as_unsigned that makes sure the attribute doesn't need
  reprocessing.

- attribute::set_unsigned needs to clear the requires_reprocessing flag,
  otherwise it stays set when reprocessing DW_FORM_rnglistx and
  DW_FORM_loclistx attributes.

There's another assert that we hit once the next patch is applied, but
since it's in the same vein as the changes in this patch, I included it
in this patch:

- attribute::form_is_unsigned must handle form DW_FORM_loclistx,
  otherwise we hit the assert when trying to call set_unsigned for an
  attribute of this form.  DW_FORM_rnglistx is already handled.

gdb/ChangeLog:

PR gdb/26813
* dwarf2/attribute.h (struct attribute) <set_unsigned>: Clear
requires_reprocessing flag.
* dwarf2/attribute.c (attribute::form_is_unsigned): Handle
DW_FORM_loclistx.
(attribute::form_requires_reprocessing): Handle DW_FORM_rnglistx
and DW_FORM_loclistx.
* dwarf2/read.c (read_attribute_reprocess): Use set_unsigned
instead of set_address for DW_FORM_loclistx and
DW_FORM_rnglistx.

Change-Id: I06c156fa3913ca98e4e39085f4ef171645b4bc1e

gdb/dwarf: remove unnecessary check in read_{rng,loc}list_index

In read_rnglist_index and read_loclist_index, we check that both the
start and end of the offset that we read from the offset table are
within the section.  I think it's unecessary to do both: if the end of
the offset is within the section, then surely the start of the offset is
within it.

Remove the check for the start of the offset in both functions.

gdb/ChangeLog:

* dwarf2/read.c (read_loclist_index): Remove bound check for
start of offset.
(read_rnglist_index): Likewise.

Change-Id: I7b57ddf4f8a8a28971738f0e3f3af62108f9e19a

gdb/dwarf: add missing bound check to read_loclist_index

read_rnglist_index has a bound check to make sure that we don't go past
the end of the section while reading the offset, but read_loclist_index
doesn't.  Add it to read_loclist_index.

gdb/ChangeLog:

* dwarf2/read.c (read_loclist_index): Add bound check for the end
of the offset.

Change-Id: Ic4b55c88860fdc3e007740949c78ec84cdb4da60

gdb/dwarf: fix bound check in read_rnglist_index

I think this check in read_rnglist_index is wrong:

      /* Validate that reading won't go beyond the end of the section.  */
      if (start_offset + cu->header.offset_size > rnglist_base + section->size)
        error (_("Reading DW_FORM_rnglistx index beyond end of"
                 ".debug_rnglists section [in module %s]"),
               objfile_name (objfile));

The addition `rnglist_base + section->size` doesn't make sense.
rnglist_base is an offset into `section`, so it doesn't make sense to
add it to `section`'s size.  `start_offset` also is an offset into
`section`, so we should just compare it to just `section->size`.

gdb/ChangeLog:

* dwarf2/read.c (read_rnglist_index): Fix bound check.

Change-Id: If0ff7c73f4f80f79aac447518f4e8f131f2db8f2

gdb/dwarf: change read_loclist_index complaints into errors

Unlike read_rnglists_index, read_loclist_index uses complaints when it
detects an inconsistency (a DW_FORM_loclistx value without a
.debug_loclists section or an offset outside of the section).  I really
think they should be errors, since there's no point in continuing if
this situation happens, we will likely segfault or read garbage.

gdb/ChangeLog:

* dwarf2/read.c (read_loclist_index): Change complaints into
errors.

Change-Id: Ic3a1cf6e682d47cb6e739dd76fd7ca5be2637e10

readelf: Add 'R' and 'D' to "Key to Flags:"

Add "R (retain)" and "D (mbind)" to "Key to Flags:".

PR binutils/27281
* readelf.c (process_section_headers): Add 'R' and 'D' to
"Key to Flags:".
* testsuite/binutils-all/retain1a.d: Updated.

PR27311, ld.bfd (symbol from plugin): undefined reference

A default versioned symbol definition in a shared library is
overridden by an unversioned definition in a regular object file, and
thus should not be reason to make an as-needed library needed.

bfd/
PR 27311
* elflink.c (_bfd_elf_add_default_symbol): Add override parameter.
Use when handling default versioned symbol.  Rename existing
override variable to nondef_override and use for non-default
versioned symbol.
(elf_link_add_object_symbols): Adjust call to suit.  Don't
pull in as-needed libraries when override is set.
ld/
* testsuite/ld-plugin/pr27311.d,
* testsuite/ld-plugin/pr27311.ver,
* testsuite/ld-plugin/pr27311a.c,
* testsuite/ld-plugin/pr27311b.c,
* testsuite/ld-plugin/pr27311c.c: New testcase.
* testsuite/ld-plugin/lto.exp: Run it.  Correct PR14918 and
PR12982 entries.

[gdb/symtab] Fix assert in write_one_signatured_type

When running test-case gdb.dwarf2/fission-reread.exp with target board
cc-with-gdb-index, we run into an abort during the generation of the gdb-index
by cc-with-tweaks.sh:
...
build/gdb/testsuite/cache/gdb.sh: line 1: 27275 Aborted  (core dumped)
...

This can be reproduced on the command line like this:
...
$ gdb -batch ./outputs/gdb.dwarf2/fission-reread/fission-reread \
  -ex 'save gdb-index  ./outputs/gdb.dwarf2/fission-reread'
warning: Could not find DWO TU fission-reread.dwo(0x9022f1ceac7e8b19) \
  referenced by TU at offset 0x0 [in module fission-reread]
warning: Could not find DWO CU fission-reread.dwo(0x807060504030201) \
  referenced by CU at offset 0x561 [in module fission-reread]
Aborted (core dumped)
...

The abort is a segfault due to a using a nullptr psymtab in
write_one_signatured_type.

The problem is that we're trying to write index entries for the type unit
with signature:
...
(gdb) p /x entry->signature
$2 = 0x9022f1ceac7e8b19
...
which is a skeleton type unit:
...
Contents of the .debug_types section:

  Compilation Unit @ offset 0x0:
   Length:        0x4a (32-bit)
   Version:       4
   Abbrev Offset: 0x165
   Pointer Size:  4
   Signature:     0x9022f1ceac7e8b19
   Type Offset:   0x0
 <0><17>: Abbrev Number: 2 (DW_TAG_type_unit)
    <18>   DW_AT_comp_dir    : /tmp/src/gdb/testsuite
    <2f>   DW_AT_GNU_dwo_name: fission-reread.dwo
    <42>   DW_AT_GNU_pubnames: 0x0
    <46>   DW_AT_GNU_pubtypes: 0x0
    <4a>   DW_AT_GNU_addr_base: 0x0
...
referring to a .dwo file, but as the warnings show, the .dwo file is not
found.

Fix this by skipping the type unit in write_one_signatured_type if
psymtab == nullptr.

Tested on x86_64-linux.

gdb/ChangeLog:

2021-02-02  Tom de Vries  <tdevries@suse.de>

PR symtab/24620
* dwarf2/index-write.c (write_one_signatured_type): Skip if
psymtab == nullptr.

gdb/testsuite/ChangeLog:

2021-02-02  Tom de Vries  <tdevries@suse.de>

PR symtab/24620
* gdb.dwarf2/fission-reread.exp: Add test-case.

Automatic date update in version.in

Add Genode target support

* configure.tgt: Add *-*-genode* as a target for AArch64 and x86.

[gdb/testsuite] Fix gdb.dwarf2/fission-reread.exp with .gdb_index

When running test-case gdb.dwarf2/fission-reread.exp with target board
cc-with-gdb-index, we run into:
...
gdb compile failed, warning: Could not find DWO TU \
  fission-reread.dwo(0x9022f1ceac7e8b19) referenced by TU at offset 0x0 \
  [in module outputs/gdb.dwarf2/fission-reread/fission-reread]
...
The problem is that the .dwo file is not found.

There's code added in the .exp file to make sure the .dwo can be found:
...
 # Make sure we can find the .dwo file, regardless of whether we're
 # running in parallel mode.
 gdb_test_no_output "set debug-file-directory [file dirname $binfile]" \
     "set debug-file-directory"
...
This works normally, but not for the gdb invocation done by cc-with-tweaks.sh
for target board cc-with-gdb-index.

Fix this by finding the full path to the .dwo file and passing it
to the compilation.

Tested on x86_64-linux with native and target boards cc-with-gdb-index,
cc-with-debug-names and readnow.

gdb/testsuite/ChangeLog:

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

* gdb.dwarf2/fission-base.S: Pass -DDWO=$dwo.
* gdb.dwarf2/fission-loclists-pie.S: Same.
* gdb.dwarf2/fission-loclists.S: Same.
* gdb.dwarf2/fission-multi-cu.S: Same.
* gdb.dwarf2/fission-reread.S: Same.
* gdb.dwarf2/fission-base.exp: Use DWO.
* gdb.dwarf2/fission-loclists-pie.exp: Same.
* gdb.dwarf2/fission-loclists.exp: Same.
* gdb.dwarf2/fission-multi-cu.exp: Same.
* gdb.dwarf2/fission-reread.exp: Same.

Wrong operand for SADDR (rl78)

PR 27254
* elf32-rl78.c (rl78_elf_relocate_section): Fix calculation of
offset for the R_RL78_RH_SADDR relocation.

Small updates to the 'how to make a release' document following from the 2.35.2 release

ld --defsym

This makes --defsym support the same expressions as assignment in a
script.  For example, --defsym 'HIDDEN(foo=0)', will define a hidden
visibility foo.

* ldgram.y (defsym_expr): Use assignment rule.
* ldlex.h (ldlex_defsym): Delete.
* ldlex.l (DEFSYMEXP, ldlex_defsym): Delete.

ld script expression parsing

Parsing symbol or file/section names in ld linker scripts is a little
complicated.  Inside SECTIONS, a name might be the start of an
expression or an output section.  Is ".foo=x-y" a fancy section name
or is it the expression ".foo = x - y"?  It isn't possible for a
single lookahead parser to decide, so the answer in this case is
that it's a section name.  This is the reason why everyone writes
linker script assignment expressions with lots of white-space.

However, there are many places where the parser knows for sure that an
expression is expected.  Those could be written without whitespace
given the first change to ldlex.l below.  Unfortunately, that runs
into a lookahead problem.  Optional expressions at the end of an
output section statement require the parser to look ahead one token in
expression context.  For this example from standard scripts
  .interp             : { *(.interp) }
  .note.gnu.build-id  : { *(.note.gnu.build-id) }
at the end of the .interp closing brace, the parser is looking for
a possible memspec, phdr, fill or even an optional comma.  The next
token is a NAME, but in expression context that NAME now doesn't
include '-' as a valid char.  So the lookahead NAME is
".note.gnu.build" with an unexpected "-id" syntax error before the
colon.  The rest of the patch involving ldlex_backup arranges to
discard that NAME token so that it will be rescanned in the proper
script context.

* ldgram.y (section): Call ldlex_backup.  Remove empty action.
* ldlex.h (ldlex_backup): Declare.
* ldlex.l (<EXPRESSION>NAME): Don't use NOCFILENAMECHAR set of
chars, use SYMBOLNAMECHAR.
(ldlex_backup): New function.

gdb: unify parts of the Linux and FreeBSD core dumping code

While reviewing the Linux and FreeBSD core dumping code within GDB for
another patch series, I noticed that the code that collects the
registers for each thread and writes these into ELF note format is
basically identical between Linux and FreeBSD.

This commit merges this code and moves it into the gcore.c file,
which seemed like the right place for generic writing a core file
code.

The function find_signalled_thread is moved from linux-tdep.c despite
not being shared.  A later commit will make use of this function.

There are a couple of minor changes to the FreeBSD target after this
commit, but I believe that these are changes for the better:

(1) For FreeBSD we always used to record the thread-id in the core file by
using ptid_t.lwp ().  In contrast the Linux code did this:

    /* For remote targets the LWP may not be available, so use the TID.  */
    long lwp = ptid.lwp ();
    if (lwp == 0)
      lwp = ptid.tid ();

Both target now do this:

    /* The LWP is often not available for bare metal target, in which case
       use the tid instead.  */
    if (ptid.lwp_p ())
      lwp = ptid.lwp ();
    else
      lwp = ptid.tid ();

Which is equivalent for Linux, but is a change for FreeBSD.  I think
that all this means is that in some cases where GDB might have
previously recorded a thread-id of 0 for each thread, we might now get
something more useful.

(2) When collecting the registers for Linux we collected into a zero
initialised buffer.  By contrast on FreeBSD the buffer is left
uninitialised.  In the new code the buffer is always zero initialised.
I suspect once the registers are copied into the buffer there's
probably no gaps left so this makes no difference, but if it does then
using zeros rather than random bits of GDB's memory is probably a good
thing.

Otherwise, there should be no other user visible changes after this
commit.

Tested this on x86-64/GNU-Linux and x86-64/FreeBSD-12.2 with no
regressions.

gdb/ChangeLog:

* Makefile.in (HFILES_NO_SRCDIR): Add corefile.h.
* gcore.c (struct gcore_collect_regset_section_cb_data): Moved
here from linux-tdep.c and given a new name.  Minor cleanups.
(gcore_collect_regset_section_cb): Likewise.
(gcore_collect_thread_registers): Likewise.
(gcore_build_thread_register_notes): Likewise.
(gcore_find_signalled_thread): Likewise.
* gcore.h (gcore_build_thread_register_notes): Declare.
(gcore_find_signalled_thread): Declare.
* fbsd-tdep.c: Add 'gcore.h' include.
(struct fbsd_collect_regset_section_cb_data): Delete.
(fbsd_collect_regset_section_cb): Delete.
(fbsd_collect_thread_registers): Delete.
(struct fbsd_corefile_thread_data): Delete.
(fbsd_corefile_thread): Delete.
(fbsd_make_corefile_notes): Call
gcore_build_thread_register_notes instead of the now deleted
FreeBSD code.
* linux-tdep.c: Add 'gcore.h' include.
(struct linux_collect_regset_section_cb_data): Delete.
(linux_collect_regset_section_cb): Delete.
(linux_collect_thread_registers): Delete.
(linux_corefile_thread): Call
gcore_build_thread_register_notes.
(find_signalled_thread): Delete.
(linux_make_corefile_notes): Call gcore_find_signalled_thread.

ldgram.y low_level_library_NAME_list

Beginning a new rule hidden inside another rule is horrible.

* ldgram.y: Whitespace fixes.

Re: ld: Add a test for PR ld/27259

* testsuite/ld-elf/pr27259.d: Correct sh_link match.

PR27283 gas for alpha fails to build with gcc 11

PR 27283
* config/tc-alpha.c (insert_operand): Delete dead code.

Automatic date update in version.in

sim: cgen-trace: tweak printf call

GCC warns that we pass a non-string literal as the format string,
so add an explicit "%s" to make it happy.

sim: bpf: fix mainloop extract call

The extract function takes the argbuf, not the scache.

sim: bpf/or1k: fix CGEN_TRACE_EXTRACT name

We renamed these years ago, but it looks like the cgen core missed the
TRACE_EXTRACT function, so these new ports still used the incompatible
common name.  Fix those ports to use the right func.

sim: cgen-accfp: Fix pointer sign warnings

When compiling we get the following warnings:

  common/cgen-accfp.c: In function 'fixsfsi':
  common/cgen-accfp.c:370:18: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
     sim_fpu_to32i (&res, &op1, sim_fpu_round_near);
                    ^
  common/cgen-accfp.c: In function 'fixdfsi':
  common/cgen-accfp.c:381:18: warning: pointer targets in passing argument 1 of 'sim_fpu_to32i' differ in signedness [-Wpointer-sign]
     sim_fpu_to32i (&res, &op1, sim_fpu_round_near);
                    ^

sim: v850: cleanup build warnings

This port only had one minor warning left in it, so fix it and then
enable -Werror behavior by deleting the macro call.  We'll use the
common default now (which is -Werror).

sim: v850: fix handling of SYS_times

My recent rewrite of the nltvals generator fixed a bug where SYS_times
was not being exported for v850.  But that in turn uncovered this bug
where the SYS_times codepath had a compile error.

sim: moxie: cleanup build warnings

This port only had one minor warning left in it, so fix it and then
enable -Werror behavior by deleting the macro call.  We'll use the
common default now (which is -Werror).

sim: common: change gennltvals helper to Python

This tool is only run by developers and not in a release build,
so rewrite it in Python to make it more maintainable.

Automatic date update in version.in

sim: m68hc11: fix printf size warnings

GCC complains %llu is wrong for signed64, so switch to PRIi64.

sim: m68hc11: localize a few functions

These are only used in this file and lack prototypes, so gcc
complains about it.  Add static everywhere to clean that up.

sim: m68hc11: tweak printf-style funcs

GCC complains that we past non-string literals to a printf style func,
so put a %s in here to keep it quiet.

sim: m68hc11: include stdlib.h for prototypes

These files use abort() & strtod(), so include stdlib.h for them.

sim: watchpoints: change sizeof_pc to sizeof(sim_cia)

Existing ports already have sizeof_pc set to the same size as sim_cia,
so simply make that part of the core code.  We already assume this in
places by way of sim_pc_{get,set}, and this is how it's documented in
the sim-base.h API.

There is code to allow sims to pick different register word sizes from
address sizes, but most ports use the defaults for both (32-bits), and
the few that support multiple register sizes never change the address
size (so address defaults to register).  I can't think of any machine
where the register hardware size would be larger than the address word
size either.  We have ABIs that behave that way (e.g. x32), but the
hardware is still equivalent register sized.

sim: profile: fix bucketing with 64-bit targets

When the target's PC is 64-bits, this shift expands into a range of
8 * 8 - 1 which doesn't work with 32-bit constants.  Force it to be
a 64-bit value all the time and let the compiler truncate it.

sim: m68hc11: stop making hardware conditional

This port doesn't build if these hardware modules are omitted, and
there's no reason we need to make it conditional at build time, so
always enable it.  The hardware devices only get turned on if the
user requests it at runtime via hardware settings.

sim: hw: replace fgets with getline

This avoids fixed sized buffers on the stack.

sim: common: sort nltvals.def

This was largely already done, but I think people didn't quite notice.

sim: readd myself as a maintainer

Automatic date update in version.in

[gdb/breakpoint] Fix stepping past non-stmt line-table entries

Consider the test-case small.c:
...
$ cat -n small.c
     1  __attribute__ ((noinline, noclone))
     2  int foo (char *c)
     3  {
     4    asm volatile ("" : : "r" (c) : "memory");
     5    return 1;
     6  }
     7
     8  int main ()
     9  {
    10    char tpl1[20] = "/tmp/test.XXX";
    11    char tpl2[20] = "/tmp/test.XXX";
    12    int fd1 = foo (tpl1);
    13    int fd2 = foo (tpl2);
    14    if (fd1 == -1) {
    15      return 1;
    16    }
    17
    18    return 0;
    19  }
...

Compiled with gcc-8 and optimization:
...
$ gcc-8 -O2 -g small.c
...

We step through the calls to foo, but fail to visit line 13:
...
12   int fd1 = foo (tpl1);
(gdb) step
foo (c=c@entry=0x7fffffffdea0 "/tmp/test.XXX") at small.c:5
5   return 1;
(gdb) step
foo (c=c@entry=0x7fffffffdec0 "/tmp/test.XXX") at small.c:5
5   return 1;
(gdb) step
main () at small.c:14
14   if (fd1 == -1) {
(gdb)
...

This is caused by the following.  The calls to foo are implemented by these
insns:
....
  4003df:       0f 29 04 24             movaps %xmm0,(%rsp)
  4003e3:       0f 29 44 24 20          movaps %xmm0,0x20(%rsp)
  4003e8:       e8 03 01 00 00          callq  4004f0 <foo>
  4003ed:       48 8d 7c 24 20          lea    0x20(%rsp),%rdi
  4003f2:       89 c2                   mov    %eax,%edx
  4003f4:       e8 f7 00 00 00          callq  4004f0 <foo>
  4003f9:       31 c0                   xor    %eax,%eax
...
with corresponding line table entries:
...
INDEX  LINE   ADDRESS            IS-STMT
8      12     0x00000000004003df Y
9      10     0x00000000004003df
10     11     0x00000000004003e3
11     12     0x00000000004003e8
12     13     0x00000000004003ed
13     12     0x00000000004003f2
14     13     0x00000000004003f4 Y
15     13     0x00000000004003f4
16     14     0x00000000004003f9 Y
17     14     0x00000000004003f9
...

Once we step out of the call to foo at 4003e8, we land at 4003ed, and gdb
enters process_event_stop_test to figure out what to do.

That entry has is-stmt=n, so it's not the start of a line, so we don't stop
there.  However, we do update ecs->event_thread->current_line to line 13,
because the frame has changed (because we stepped out of the function).

Next we land at 4003f2.  Again the entry has is-stmt=n, so it's not the start
of a line, so we don't stop there.  However, because the frame hasn't changed,
we don't update update ecs->event_thread->current_line, so it stays 13.

Next we land at 4003f4.  Now is-stmt=y, so it's the start of a line, and we'd
like to stop here.

But we don't stop because this test fails:
...
  if ((ecs->event_thread->suspend.stop_pc == stop_pc_sal.pc)
      && (ecs->event_thread->current_line != stop_pc_sal.line
          || ecs->event_thread->current_symtab != stop_pc_sal.symtab))
    {
...
because ecs->event_thread->current_line == 13 and stop_pc_sal.line == 13.

Fix this by resetting ecs->event_thread->current_line to 0 if is-stmt=n and
the frame has changed, such that we have:
...
12        int fd1 = foo (tpl1);
(gdb) step
foo (c=c@entry=0x7fffffffdbc0 "/tmp/test.XXX") at small.c:5
5         return 1;
(gdb) step
main () at small.c:13
13        int fd2 = foo (tpl2);
(gdb)
...

Tested on x86_64-linux, with gcc-7 and gcc-8.

gdb/ChangeLog:

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

PR breakpoints/26063
* infrun.c (process_event_stop_test): Reset
ecs->event_thread->current_line to 0 if is-stmt=n and frame has
changed.

gdb/testsuite/ChangeLog:

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

PR breakpoints/26063
* gdb.dwarf2/dw2-step-out-of-function-no-stmt.c: New test.
* gdb.dwarf2/dw2-step-out-of-function-no-stmt.exp: New file.

[gdb/testsuite] Fix gdb.opt/solib-intra-step.exp with -m32 and gcc-10

When running test-case gdb.opt/solib-intra-step.exp with target board
unix/-m32 and gcc-10, I run into:
...
(gdb) step^M
__x86.get_pc_thunk.bx () at ../sysdeps/i386/crti.S:68^M
68      ../sysdeps/i386/crti.S: No such file or directory.^M
(gdb) step^M
shlib_second (dummy=0) at solib-intra-step-lib.c:23^M
23        abort (); /* second-hit */^M
(gdb) FAIL: gdb.opt/solib-intra-step.exp: second-hit
...

The problem is that the test-case expects to step past the retry line,
which is optional.

Fix this by removing the state tracking logic from the gdb_test_multiples.  It
makes the test more difficult to understand, and doesn't specifically test for
faulty gdb behaviour.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.opt/solib-intra-step.exp: Remove state tracking logic.

PR27271, c6x-uclinux-ld segfaults linking ld-uClibc-1.0.37.so

bfd/
PR 27271
* elflink.c (bfd_elf_link_record_dynamic_symbol): Don't segfault
on symbols defined in absolute or other special sections.
ld/
* testsuite/ld-tic6x/tic6x.exp: Add pr27271 test.

Automatic date update in version.in

gdb: remove unneeded switch_to_thread from thr_try_catch_cmd

I spotted that every time thr_try_catch_cmd is called GDB has already
switched to the required thread.  The call to switch_to_thread at the
head of thr_try_catch_cmd is therefore redundant.

This commit replaces the call to switch_to_thread with an assertion
that we already have the required thread selected.

I also extended the header comment on thr_try_catch_cmd to make it
clearer when this function could throw an exception.

There should be no user visible changes after this commit.

gdb/ChangeLog:

* thread.c (thr_try_catch_cmd): Replace swith_to_thread with an
assert.  Extend the header comment.

gdb/tui: remove special handling of locator/status window

The locator window, or status window as it is sometimes called is
handled differently to all the other windows.

The reason for this is that the class representing this
window (tui_locator_window) does two jobs, first this class represents
a window just like any other that has space on the screen and fills
the space with content.  The second job is that this class serves as a
storage area to hold information about the current location that the
TUI windows represent, so the class has members like 'addr' and
'line_no', for example which are used within this class, and others
when they want to know which line/address the TUI windows should be
showing to the user.

Because of this dual purpose we must always have an instance of the
tui_locator_window so that there is somewhere to store this location
information.

The result of this is that the locator window must never be deleted
like other windows, which results in some special case code.

In this patch I propose splitting the two roles of the
tui_locator_window class.  The tui_locator_window class will retain
just its window drawing parts, and will be treated just like any other
window.  This should allow all special case code for this window to be
deleted.

The other role, that of tracking the current tui location will be
moved into a new class (tui_location_tracker), of which there will be
a single global instance.  All of the places where we previously use
the locator window to get location information will now be updated to
get this from the tui_location_tracker.

There should be no user visible changes after this commit.

gdb/ChangeLog:

* Makefile.in (SUBDIR_TUI_SRCS): Add tui/tui-location.c.
(HFILES_NO_SRCDIR): Add tui/tui-location.h.
* tui/tui-data.h (TUI_STATUS_WIN): Define.
(tui_locator_win_info_ptr): Delete declaration.
* tui/tui-disasm.c: Add 'tui/tui-location.h' include.
(tui_disasm_window::set_contents): Fetch state from tui_location
global.
(tui_get_begin_asm_address): Likewise.
* tui/tui-layout.c (tui_apply_current_layout): Remove special case
for locator window.
(get_locator_window): Delete.
(initialize_known_windows): Treat locator window just like all the
rest.
* tui/tui-source.c: Add 'tui/tui-location.h' include.
(tui_source_window::set_contents): Fetch state from tui_location
global.
(tui_source_window::showing_source_p): Likewise.
* tui/tui-stack.c: Add 'tui/tui-location.h' include.
(_locator): Delete.
(tui_locator_win_info_ptr): Delete.
(tui_locator_window::make_status_line): Fetch state from
tui_location global.
(tui_locator_window::rerender): Remove check of 'handle',
reindent function body.
(tui_locator_window::set_locator_fullname): Delete.
(tui_locator_window::set_locator_info): Delete.
(tui_update_locator_fullname): Delete.
(tui_show_frame_info): Likewise.
(tui_show_locator_content): Access window through TUI_STATUS_WIN.
* tui/tui-stack.h (tui_locator_window::set_locator_info): Moved to
tui/tui-location.h and renamed to
tui_location_tracker::set_location.
(tui_locator_window::set_locator_fullname): Moved to
tui/tui-location.h and renamed to
tui_location_tracker::set_fullname.
(tui_locator_window::full_name): Delete.
(tui_locator_window::proc_name): Delete.
(tui_locator_window::line_no): Delete.
(tui_locator_window::addr): Delete.
(tui_locator_window::gdbarch): Delete.
(tui_update_locator_fullname): Delete declaration.
* tui/tui-wingeneral.c (tui_refresh_all): Removed special handling
for locator window.
* tui/tui-winsource.c: Add 'tui/tui-location.h' include.
(tui_display_main): Call function on tui_location directly.
* tui/tui.h (enum tui_win_type): Add STATUS_WIN.
* tui/tui-location.c: New file.
* tui/tui-location.h: New file.

[gdb/testsuite] Fix gdb.arch/i386-gnu-cfi.exp

When running test-case gdb.arch/i386-gnu-cfi.exp with target board unix/-m32, I get:
...
(gdb) up 3^M
79      abort.c: No such file or directory.^M
(gdb) FAIL: gdb.arch/i386-gnu-cfi.exp: shift up to the modified frame
...

The preceding backtrace looks like this:
...
(gdb) bt^M
 #0  0xf7fcf549 in __kernel_vsyscall ()^M
 #1  0xf7ce8896 in __libc_signal_restore_set (set=0xffffc3bc) at \
     ../sysdeps/unix/sysv/linux/internal-signals.h:104^M
 #2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:47^M
 #3  0xf7cd0314 in __GI_abort () at abort.c:79^M
 #4  0x0804919f in gate (gate=0x8049040 <abort@plt>, data=0x0) at gate.c:3^M
 #5  0x08049176 in main () at i386-gnu-cfi.c:27^M
...
with function gate at position #4, while on another system where the test passes,
I see instead function gate at position #3.

Fix this by capturing the position of function gate in the backtrace, and
using that in the rest of the test instead of hardcoded constant 3.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.arch/i386-gnu-cfi.exp: Capture the position of function gate
in the backtrace, and use that in the rest of the test instead of
hardcoded constant 3.  Use "frame" instead of "up" for robustness.

[gdb/testsuite] Fix g0 search in gdb.arch/i386-sse-stack-align.exp

When running test-case gdb.arch/i386-sse-stack-align.exp on target board
unix/-m32, I run into:
...
(gdb) print (int) g0 ()^M
Invalid data type for function to be called.^M
(gdb) FAIL: gdb.arch/i386-sse-stack-align.exp: print (int) g0 ()
...

Gdb is supposed to use minimal symbol g0:
...
$ nm i386-sse-stack-align | grep g0
08049194 t g0
...
but instead it finds a g0 symbol in the debug info of libm, specifically in
./sysdeps/ieee754/ldbl-96/e_lgammal_r.c.

Fix this by renaming g[0-4] to test_g[0-4].

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.arch/i386-sse-stack-align.S: Rename g[0-4] to test_g[0-4].
* gdb.arch/i386-sse-stack-align.c: Same.
* gdb.arch/i386-sse-stack-align.exp: Same.

gdb: rename get_type_arch to type::arch

... and update all users.

gdb/ChangeLog:

* gdbtypes.h (get_type_arch): Rename to...
(struct type) <arch>: ... this, update all users.

Change-Id: I0e3ef938a0afe798ac0da74a9976bbd1d082fc6f

gdb: rename type::{arch,objfile} -> type::{arch_owner,objfile_owner}

I think this makes the names of the methods clearer, especially for the
arch.  The type::arch method (which gets the arch owner, or NULL if the
type is not arch owned) is easily confused with the get_type_arch method
(which returns an arch no matter what).  The name "arch_owner" will make
it intuitive that the method returns NULL if the type is not arch-owned.

Also, this frees the type::arch name, so we will be able to morph the
get_type_arch function into the type::arch method.

gdb/ChangeLog:

* gdbtypes.h (struct type) <arch>: Rename to...
<arch_owner>: ... this, update all users.
<objfile>: Rename to...
<objfile_owner>: ... this, update all users.

Change-Id: Ie7c28684c7b565adec05a7619c418c69429bd8c0

Improve windres's handling of pathnames containing special characters on Windows platforms.

 PR 4356
 * windres.c (quot): Use double quotes to protect strings on
 Windows platforms.

ld: Add a test for PR ld/27259

PR ld/27259
* testsuite/ld-elf/pr27259.d: New file.
* testsuite/ld-elf/pr27259.s: Likewise.

Fix binutils tools so that they can cope with the special /dev/null file when run on Windows systems.

 PR 27252
 * bucomm.c (get_file_size): Add code to handle /dev/null on
 Windows systems.
 * elfedit.c (check_file): Likewise.

gold: Skip address size and segment selector for DWARF5

The .debug_line secton in DWARF5 has a byte for address size and a byte
for segment selector after DWARF version.  Skip them for DWARF5.

PR gold/27246
* dwarf_reader.cc (Sized_dwarf_line_info::read_header_prolog):
Skip address size and segment selector for DWARF5.

gdb/testsuite: unset XDG_CONFIG_HOME

Since this commit:

  commit 64aaad6349d2b2c45063a5383f877ce9a3a0c354
  Date:   Fri Sep 25 14:50:56 2020 +0100

      gdb: use get_standard_config_dir when looking for .gdbinit

GDB has been checking for ${XDG_CONFIG_HOME}/gdb/gdbinit on startup.

Most tests pass -nx to GDB to block loading of gdbinit files, but
there are a few tests (e.g. gdb.base/gdbinit-history.exp) that don't
use -nx and instead setup a fake HOME directory containing a gdbinit
file.

However, since the above commit, if XDG_CONFIG_HOME is set then once
-nx is no longer being passed GDB will load any gdbinit file it finds
in that directory, which could cause the test to fail.

As a concrete example:

  $ mkdir -p fake_xdg_config_home/gdb/
  $ cat <<EOF >fake_xdg_config_home/gdb/gdbinit
  echo goodbye\n
  quit
  EOF
  $ export XDG_CONFIG_HOME=$PWD/fake_xdg_config_home
  $ make check-gdb TESTS="gdb.base/gdbinit-history.exp"

Should result in the test failing.

The solution I propose is to unset XDG_CONFIG_HOME in
default_gdb_init, we already unset a bunch of environment variables in
this proc.

gdb/testsuite/ChangeLog:

* lib/gdb.exp (default_gdb_init): Unset XDG_CONFIG_HOME.

gdb: update comment for execute_command_to_string

The function execute_command_to_string had two header comments, one in
gdbcmd.h and one in top.c.

This commit merges the two comments into one and places this comment
in gdbcmd.h.  The comment in top.c is updated to just reference
gdbcmd.h.

gdb/ChangeLog:

* gdbcmd.h (execute_command_to_string): Update comment.
* top.c (execute_command_to_string): Update header comment.

[gdb/breakpoints] Fix longjmp master breakpoint with separate debug info

When running test-case gdb.base/longjmp.exp with target board unix/-m32, we
run into:
...
(gdb) next^M
Warning:^M
Cannot insert breakpoint 0.^M
Cannot access memory at address 0x7dbf7353^M
^M
__libc_siglongjmp (env=0x804a040 <env>, val=1) at longjmp.c:28^M
28        longjmps++;^M
(gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1)
...

The failure to access memory happens in i386_get_longjmp_target and is due to
glibc having pointer encryption (aka "pointer mangling" or "pointer guard") of
the long jump buffer.  This is a known problem.

In create_longjmp_master_breakpoint (which attempts to install a master
longjmp breakpoint) a preference scheme is present, which installs a
probe breakpoint if a libc:longjmp probe is present, and otherwise falls back
to setting breakpoints at the names in the longjmp_names array.

But in fact, both the probe breakpoint and the longjmp_names breakpoints are
set.  The latter ones are set when processing libc.so.debug, and the former
one when processing libc.so.  In other words, this is the longjmp variant of
PR26881, which describes the same problem for master exception breakpoints.

This problem only triggers when the glibc debug info package is installed,
which is not due to the debug info itself in libc.so.debug, but due to the
minimal symbols (because create_longjmp_master_breakpoint uses minimal symbols
to translate the longjmp_names to addresses).

The problem doesn't trigger for -m64, because there tdep->jb_pc_offset is not
set.

Fix this similar to commit 1940319c0ef (the fix for PR26881): only install
longjmp_names breakpoints in libc.so/libc.so.debug if installing the
libc:longjmp probe in libc.so failed.

Tested on x86_64-linux.

gdb/ChangeLog:

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

PR breakpoints/27205
* breakpoint.c (create_longjmp_master_breakpoint_probe)
(create_longjmp_master_breakpoint_names): New function, factored out
of ...
(create_longjmp_master_breakpoint): ... here.  Only try to install
longjmp_names breakpoints in libc.so/libc.so.debug if installing probe
breakpoint in libc.so failed.

PR27259, SHF_LINK_ORDER self-link

This stops ld from endless looping on SHF_LINK_ORDER sh_link loops.

bfd/
PR 27259
* elflink.c (_bfd_elf_gc_mark_extra_sections): Use linker_mark to
prevent endless looping of linked-to sections.
ld/
PR 27259
* ldelf.c (ldelf_before_place_orphans): Use linker_mark to
prevent endless looping of linked-to sections.

[gdb/testsuite] Fix gdb.ada/out_of_line_in_inlined.exp with -m32 and gcc-10

When running test-case gdb.ada/out_of_line_in_inlined.exp with target board
unix/-m32 on a system with gcc-10 default compiler, we run into:
...
(gdb) break foo_o224_021.child1.child2^M
Breakpoint 1 at 0x804ba59: foo_o224_021.child1.child2. (3 locations)^M
(gdb) FAIL: gdb.ada/out_of_line_in_inlined.exp: scenario=all: \
  break foo_o224_021.child1.child2
...

The test does not expect the "3 locations" part.

Fix this by using gdb_breakpoint instead of gdb_test.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.ada/out_of_line_in_inlined.exp: Use gdb_breakpoint.

[gdb/testsuite] Fix ERROR in gdb.dwarf2/dw2-out-of-range-end-of-seq.exp

When running test-case gdb.dwarf2/dw2-out-of-range-end-of-seq.exp on a
system with debug packages installed, I run into:
...
(gdb) maint info line-table^M
  ... <lots of output> ...
ERROR: internal buffer is full.
UNRESOLVED: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: \
  END with address 1 eliminated
...

Fix this by limiting the output of the command using a regexp.

I also noticed that when making the regexp match nothing, meaning
the command has no output, the test didn't FAIL.  Fixed this by adding a
PASS pattern.

I also noticed that the FAIL pattern didn't work with -m32, fixed that as
well.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: Add regexp to
"maint info line-table".  Make PASS pattern more specific.  Make
FAIL pattern work for -m32.

Automatic date update in version.in

Avoid use after free with logging and debug redirect.

This patch addresses PR gdb/27133. Before it, the following succession
of commands would cause gdb to crash:

set logging redirect on
set logging debugredirect on
set logging on

The problem eventually comes down to a use after free. The function
cli_interp_base::set_logging is called with a unique_ptr argument that
holds a pointer to the redirection file. In the problematic use case,
no-one ever took ownership of that pointer (as far as unique_ptr is
concerned), so the call to its dtor at the end of the function causes
the file object to be deleted. Any later use of the pointer to the
redirection file is therefore an error.

This patch ensures that the unique_ptr is released  when required (so it
does not assume ownership anymore). The internal logic of
cli_interp_base::set_logging takes care of freeing the ui_file when it
is not necessary anymore using the saved_output.file_to_delete field.

gdb/ChangeLog:

PR gdb/27133
* cli/cli-interp.c (cli_interp_base::set_logging): Ensure the
unique_ptr is released when the wrapped pointer is kept for later
use.

gdb/testsuite/ChangeLog:

PR gdb/27133
* gdb.base/ui-redirect.exp: Add test case that ensures that
redirecting both logging and debug does not cause gdb to crash.

GDB: aarch64: Add ability to displaced step over a BR/BLR instruction

Enable displaced stepping over a BR/BLR instruction

Displaced stepping over an instruction executes a instruction in a
scratch area and then manually fixes up the PC address to leave
execution where it would have been if the instruction were in its
original location.

The BR instruction does not need modification in order to run correctly
at a different address, but the displaced step fixup method should not
manually adjust the PC since the BR instruction sets that value already.

The BLR instruction should also avoid such a fixup, but must also have
the link register modified to point to just after the original code
location rather than back to the scratch location.

This patch adds the above functionality.
We add this functionality by modifying aarch64_displaced_step_others
rather than by adding a new visitor method to aarch64_insn_visitor.
We choose this since it seems that visitor approach is designed
specifically for PC relative instructions (which must always be modified
when executed in a different location).

It seems that the BR and BLR instructions are more like the RET
instruction which is already handled specially in
aarch64_displaced_step_others.

This also means the gdbserver code to relocate an instruction when
creating a fast tracepoint does not need to be modified, since nothing
special is needed for the BR and BLR instructions there.

Regression tests showed nothing untoward on native aarch64 (though it
took a while for me to get the testcase to account for PIE).

------#####
Original observed (mis)behaviour before was that displaced stepping over
a BR or BLR instruction would not execute the function they called.
Most easily seen by putting a breakpoint with a condition on such an
instruction and a print statement in the functions they called.
When run with the breakpoint enabled the function is not called and
"numargs called" is not printed.
When run with the breakpoint disabled the function is called and the
message is printed.

--- GDB Session
~ [15:57:14] % gdb ../using-blr
Reading symbols from ../using-blr...done.
(gdb) disassemble blr_call_value
Dump of assembler code for function blr_call_value:
...
   0x0000000000400560 <+28>:    blr     x2
...
   0x00000000004005b8 <+116>:   ret
End of assembler dump.
(gdb) break *0x0000000000400560
Breakpoint 1 at 0x400560: file ../using-blr.c, line 22.
(gdb) condition 1 10 == 0
(gdb) run
Starting program: /home/matmal01/using-blr
[Inferior 1 (process 33279) exited with code 012]
(gdb) disable 1
(gdb) run
Starting program: /home/matmal01/using-blr
numargs called
[Inferior 1 (process 33289) exited with code 012]
(gdb)

Test program:
---- using-blr ----
\#include <stdio.h>
typedef int (foo) (int, int);
typedef void (bar) (int, int);
struct sls_testclass {
    foo *x;
    bar *y;
    int left;
    int right;
};

__attribute__ ((noinline))
int blr_call_value (struct sls_testclass x)
{
  int retval = x.x(x.left, x.right);
  if (retval % 10)
    return 100;
  return 9;
}

__attribute__ ((noinline))
int blr_call (struct sls_testclass x)
{
  x.y(x.left, x.right);
  if (x.left % 10)
    return 100;
  return 9;
}

int
numargs (__attribute__ ((unused)) int left, __attribute__ ((unused)) int right)
{
        printf("numargs called\n");
        return 10;
}

void
altfunc (__attribute__ ((unused)) int left, __attribute__ ((unused)) int right)
{
        printf("altfunc called\n");
}

int main(int argc, char **argv)
{
  struct sls_testclass x = { .x = numargs, .y = altfunc, .left = 1, .right = 2 };
  if (argc > 2)
  {
        blr_call (x);
  }
  else
        blr_call_value (x);
  return 10;
}

Remove extra space after @pxref in gdb.texinfo

Internally at AdaCore, documentation is still built with Texinfo 4.13.
This version gave an error when building gdb.texinfo:

../../../binutils-gdb/gdb/doc/gdb.texinfo:27672: @pxref expected braces.
../../../binutils-gdb/gdb/doc/gdb.texinfo:27672: ` {dotdebug_gdb_scripts section,,The @cod...' is too long for expansion; not expanded.

... followed by many more spurious errors that were caused by this
one.

This patch fix the problem by removing the extra space.

I don't know whether it's advisable to try to support this ancient
version of Texinfo (released in 2008 apparently); but in this
particular case the fix is trivial, so I'm checking it in.

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

* gdb.texinfo (Auto-loading extensions): Remove extraneous space.

ld: depend on libctf

Since ld may depend on libctf (if present), and libctf may be relinked
by the installation process, libctf must be installed before ld is,
or the relink may fail if it calls on symbols or symbol versions that do
not exist in any libctf already present on the system.  (If none is
present, the copy in the build tree will be automatically used, but
if one *is* present, it may take precedence and break things.)

(This is a maybe- dependency, so it will work even if libctf is
disabled.)

ChangeLog
2021-01-26  Nick Alcock  <nick.alcock@oracle.com>

PR 27250
* Makefile.def: Add install-libctf dependency to install-ld.
* Makefile.in: Regenerated.

Simplify the code at the end of objcopy's main() function.

 * objcopy.c (copy_main): Remove conditional control of the calls
 to free, simplifying the code and making it easier to detect
 typos.

ld: Fix a typo in testsuite/ld-x86-64/bnd-plt-1.d

Pass -mx86-used-note=no to assembler.

* testsuite/ld-x86-64/bnd-plt-1.d: Fix a typo.

Automatic date update in version.in

nios2: Don't disable relaxation with --gdwarf-N

GCC 11 passes --gdwarf-5 to assembler to enable DWARF5 debug info.  Don't
disable relaxation when --gdwarf-N is specified.  The assembler generated
debug information will treat the sequence of the relaxed instructions as
a single instruction.

PR gas/27243
* config/tc-nios2.c (md_begin): Don't disable relaxation with
--gdwarf-N.
* testsuite/gas/nios2/relax.d: New file.
* testsuite/gas/nios2/relax.s: Likewise.

Use debug_prefixed_printf_cond in windows-nat.c

This changes windows-nat.c and nat/windows-nat.c to use the new
debug_prefixed_printf_cond facility.  I tried this out on a Windows
build and I think it makes the output look a little nicer.

2021-01-26  Tom Tromey  <tromey@adacore.com>

* windows-nat.c (DEBUG_EXEC, DEBUG_EVENTS, DEBUG_MEM)
(DEBUG_EXCEPT): Use debug_prefixed_printf_cond.
(windows_init_thread_list, windows_nat::handle_load_dll)
(windows_nat::handle_unload_dll, windows_nat_target::resume)
(windows_nat_target::resume)
(windows_nat_target::get_windows_debug_event)
(windows_nat_target::interrupt, windows_xfer_memory)
(windows_nat_target::close): Update.
* nat/windows-nat.c (DEBUG_EVENTS): Use
debug_prefixed_printf_cond.
(matching_pending_stop, fetch_pending_stop)
(continue_last_debug_event): Update.

bfd: add elfcore_write_file_note

Adds a trivial wrapper over elfcore_write_note, primarily to be more
consistent with other ELF note helper functions and highlight NT_FILE as
one of notes handled by gdb.

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

* bfd-elf.h (elfcore_write_file_note): New function.
* elf.c (elfcore_write_file_note): New function.

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

* linux-tdep.c (linux_make_mappings_corefile_notes): Start using
elfcore_write_file_note.

Segmentation fault i386-gen

A case of inst->next being uninitialised.

* i386-gen.c (parse_template): Ensure entire template_instance
is initialised.

PR27226, ld.bfd contains huge .rodata section

This makes it possible to build ld without any compiled-in scripts,
by setting COMPILE_IN=no in the environment.  pe, beos and pdp11
targets didn't support scripts from the file system, with pdp11
nastily editing the ld/ldscripts file so that the built-in script
didn't match.

PR 27226
* emulparams/alphavms.sh: Don't set COMPILE_IN.
* emulparams/elf64_ia64_vms.sh: Likewise.
* emulparams/elf64mmix.sh: Likewise.
* emulparams/elf_iamcu.sh: Likewise.
* emulparams/elf_k1om.sh: Likewise.
* emulparams/elf_l1om.sh: Likewise.
* emulparams/mmo.sh: Likewise.
* emulparams/pdp11.sh: Set DATA_SEG_ADDR.
* scripttempl/pdp11.sc: Use it.
* emultempl/pdp11.em: Don't edit .xn script for separate_code,
instead use .xe script.  Support scripts from file system.
* emultempl/beos.em: Support scripts from file system.
* emultempl/pe.em: Likewise.
* emultempl/pep.em: Likewise.
* testsuite/ld-bootstrap/bootstrap.exp: Make tmpdir/ldscripts link.

gas testsuite tidy

This replaces skip and notarget in a number of gas tests with xfail,
the idea being that running tests might expose segmentation faults or
other serious errors even when we don't expect a test to pass.  Doing
so showed a number of cases where tests now pass, which is another
reason to avoid profligate use of notarget and skip.

* testsuite/gas/all/local-label-overflow.d: Use xfail rather than
notarget all except hppa.  Comment.
* testsuite/gas/all/sleb128-2.d: Use xfail rather than notarget.
* testsuite/gas/all/sleb128-4.d: Likewise.  Don't skip msp430.
* testsuite/gas/all/sleb128-5.d: Use xfail rather than notarget.
* testsuite/gas/all/sleb128-7.d: Likewise.
* testsuite/gas/all/sleb128-9.d: Likewise.
* testsuite/gas/elf/bignums.d: Likewise.
* testsuite/gas/elf/group0c.d: Likewise.
* testsuite/gas/elf/group1a.d: Likewise.
* testsuite/gas/elf/section-symbol-redef.d: Likewise.
* testsuite/gas/elf/section15.d: Likewise.
* testsuite/gas/elf/section4.d: Likewise.
* testsuite/gas/elf/section7.d: Likewise.
* testsuite/gas/macros/irp.d: Likewise.
* testsuite/gas/macros/repeat.d: Likewise.
* testsuite/gas/macros/rept.d: Likewise.
* testsuite/gas/macros/test2.d: Likewise.
* testsuite/gas/macros/vararg.d: Likewise.
* testsuite/gas/all/string.d: Use xfail rather than skip.
* testsuite/gas/elf/missing-build-notes.d: Likewise.
* testsuite/gas/elf/section0.d: Likewise.
* testsuite/gas/elf/section1.d: Likewise.
* testsuite/gas/elf/section10.d: Likewise.
* testsuite/gas/elf/section11.d: Likewise.
* testsuite/gas/elf/section6.d: Likewise.
* testsuite/gas/elf/symtab.d: Use xfail rather than skip, adjust hppa.
* testsuite/gas/elf/symtab.s: Don't start directives in first column.
* testsuite/gas/macros/test3.d: Don't notarget nds32.

gas byte test

skip *-*-* is a little silly, delete the test.

* testsuite/gas/all/byte.d,
* testsuite/gas/all/byte.l,
* testsuite/gas/all/byte.s: Delete.
* testsuite/gas/all/gas.exp: Don't run byte test.

pr27228 testcase

This failed on ft32, hppa, and mips-irix targets.  In the case of ft32
the problem was iterating over an array in reverse and not using the
proper condition, so BFD_RELOC_NONE was not recognised.

bfd/
* elf32-ft32.c (ft32_reloc_type_lookup): Don't miss ft32_reloc_map[0].
gas/
PR 27282
* testsuite/gas/all/none.d: Replace skip with xfail, don't xfail ft32.
* testsuite/gas/elf/pr27228.d: xfail hppa and allow OBJECT match.

gdb: Add default reggroups for ARC

There is no reggroups set in ARC.  If a "maintenance print reggroups"
command is issued, the default register set is dumped (which is fine).

However, if a new group is added via an XML file, then that will
become the _only_ group.  This behavior causes gdb.xml/tdesc-regs.exp
to fail.

Fixes gdb.xml/tdesc-regs.exp on ARC.

gdb/ChangeLog:

* arc-tdep.c (arc_add_reggroups): New function.
(arc_gdbarch_init): Call arc_add_reggroups.

Fix the date for the last entry in gdb/ChangeLog

The previous patch [1] sets the date incorrectly in the ChangeLog.
Sorry for the inconvenience.

[1]
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d56834cbfb7c1

Fix thinko in objcopy's memory freeing code.

* objcopy.c (copy_main): Fix a double free happening when both
--localize-symbols and --globalize-symbols options are invoked
together.

arc: Log "pc" value in "arc_skip_prologue"

Log the "pc" address upon entering "arc_skip_prologue".

gdb/ChangeLog:

* arc-tdep.c (arc_skip_prologue): Log "pc" address.

[gdb/testsuite] Fix gdb.threads/killed-outside.exp with -m32

When running test-case gdb.threads/killed-outside.exp with target board
unix/-m32, we run into:
...
(gdb) PASS: gdb.threads/killed-outside.exp: get pid of inferior
Executing on target: kill -9 10969    (timeout = 300)
spawn -ignore SIGHUP kill -9 10969^M
continue^M
Continuing.^M
[Thread 0xf7cb4b40 (LWP 10973) exited]^M
^M
Program terminated with signal SIGKILL, Killed.^M
The program no longer exists.^M
(gdb) FAIL: gdb.threads/killed-outside.exp: prompt after first continue
...

Fix this by allowing this output.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.threads/killed-outside.exp: Allow regular output.

[gdb/testsuite] Fix gdb.opt/solib-intra-step.exp with -m32

When running test-case gdb.opt/solib-intra-step.exp with target board
unix/-m32, we run into:
...
(gdb) step^M
__x86.get_pc_thunk.bx () at ../sysdeps/i386/crti.S:66^M
66      ../sysdeps/i386/crti.S: No such file or directory.^M
(gdb) FAIL: gdb.opt/solib-intra-step.exp: first-hit (optimized)
...

The thunk is a helper function for PIC, and given that we have line info for
it, we step into.

Fix this by allowing the step into the thunk, and stepping out of it.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.opt/solib-intra-step.exp: Handle stepping into thunk.

Automatic date update in version.in

[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