gas/testsuite: properly exclude aout in all/weakref1u

Use the (wider) predicate rather than a triplet. This eliminates the sole
i386-msdos failure in the testsuite.

x86: fold Disp32S and Disp32

The only case where 64-bit code uses non-sign-extended (can also be
considered zero-extended) displacements is when an address size override
is in place for a memory operand (i.e. particularly excluding
displacements of direct branches, which - if at all - are controlled by
operand size, and then are still sign-extended, just from 16 bits).
Hence the distinction in templates is unnecessary, allowing code to be
simplified in a number of places. The only place where logic becomes
more complicated is when signed-ness of relocations is determined in
output_disp().

The other caveat is that Disp64 cannot be specified anymore in an insn
template at the same time as Disp32. Unlike for non-64-bit mode,
templates don't specify displacements for both possible addressing
modes; the necessary adjustment to the expected ones has already been
done in match_template() anyway (but of course the logic there needs
tweaking now). Hence the single template so far doing so is split.

x86: restore masking of displacement kinds

Commit 7d5e4556a375 rendered the check near the end of what is now
i386_finalize_displacement() entirely dead for AT&T mode, since for
operands involving a displacement .unspecified will always be set. But
the logic there is bogus anyway - Intel syntax operand size specifiers
are of no interest there either. The only thing which matters in the
"displacement only" determination is .baseindex.

Of course when masking displacement kinds we should not at the same time
also mask off other attributes.

Furthermore the type mask returned by lex_got() also needs to be
adjusted: The only case where we want Disp32 (rather than Disp32S) is
when dealing with 32-bit addressing mode in 64-bit code.

x86-64: improve handling of branches to absolute addresses

There are two related problems here: The use of "addr32" on a direct
branch would, besides causing a warning, result in operands to be
permitted which mistakenly are refused without "addr32". Plus at some
point not too long ago I'm afraid it may have been me who regressed the
relocation addends emitted for such branches. Correct both problems,
adding a testcase to guard against regressing this again.

RISC-V: Update Zihintpause extension version

Because ratified Zihintpause extension has a version number of 2.0
(not 1.0), we should update the number.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_supported_std_z_ext): Update version
number of Zihintpause extension.

Automatic date update in version.in

Automatic date update in version.in

[gdb/symtab] Fix data race on per_cu->dwarf_version

When building gdb with -fsanitize=thread and gcc 12, and running test-case
gdb.dwarf2/dwz.exp, we run into a data race between thread T2 and the main
thread in the same write:
...
Write of size 1 at 0x7b200000300c:^M
    #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
    abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6252 \
    (gdb+0x82f3b3)^M
...
which is here:
...
         this_cu->dwarf_version = cu->header.version;
...

Both writes are called from the parallel for in dwarf2_build_psymtabs_hard,
this one directly:
...
    #1 process_psymtab_comp_unit gdb/dwarf2/read.c:6774 (gdb+0x8304d7)^M
    #2 operator() gdb/dwarf2/read.c:7098 (gdb+0x8317be)^M
    #3 operator() gdbsupport/parallel-for.h:163 (gdb+0x872380)^M
...
and this via the PU import:
...
    #1 cooked_indexer::ensure_cu_exists(cutu_reader*, dwarf2_per_objfile*, \
    sect_offset, bool,  bool) gdb/dwarf2/read.c:17964 (gdb+0x85c43b)^M
    #2 cooked_indexer::index_imported_unit(cutu_reader*, unsigned char const*, \
    abbrev_info const*) gdb/dwarf2/read.c:18248 (gdb+0x85d8ff)^M
    #3 cooked_indexer::index_dies(cutu_reader*, unsigned char const*, \
    cooked_index_entry const*, bool) gdb/dwarf2/read.c:18302 (gdb+0x85dcdb)^M
    #4 cooked_indexer::make_index(cutu_reader*) gdb/dwarf2/read.c:18443 \
    (gdb+0x85e68a)^M
    #5 process_psymtab_comp_unit gdb/dwarf2/read.c:6812 (gdb+0x830879)^M
    #6 operator() gdb/dwarf2/read.c:7098 (gdb+0x8317be)^M
    #7 operator() gdbsupport/parallel-for.h:171 (gdb+0x8723e2)^M
...

Fix this by setting the field earlier, in read_comp_units_from_section.

The write in cutu_reader::cutu_reader() is still needed, in case
read_comp_units_from_section is not used (run the test-case with say, target
board cc-with-gdb-index).

Make the write conditional, such that it doesn't trigger if the field is
already set by read_comp_units_from_section.  Instead, verify that the
field already has the value that we're trying to set it to.

Move this logic into into a member function set_version (in analogy to the
already present member function version) to make sure it's used consistenly,
and make the field private in order to enforce access through the member
functions, and rename it to m_dwarf_version.

While we're at it, make sure that the version is set before read, to avoid
say returning true for "per_cu.version () < 5" if "per_cu.version () == 0".

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/early-init-file.exp with -fsanitize=thread

When building gdb with -fsanitize=thread, I run into:
...
FAIL: gdb.base/early-init-file.exp: check startup version string has style \
  version
...
due to this:
...
warning: Found custom handler for signal 7 (Bus error) preinstalled.^M
warning: Found custom handler for signal 8 (Floating point exception) \
  preinstalled.^M
warning: Found custom handler for signal 11 (Segmentation fault) \
  preinstalled.^M
Some signal dispositions inherited from the environment (SIG_DFL/SIG_IGN)^M
won't be propagated to spawned programs.^M
...
appearing before the "GNU gdb (GDB) $version" line.

This is similar to the problem fixed by commit f0bbba7886f
("gdb.debuginfod/fetch_src_and_symbols.exp: fix when GDB is built with
AddressSanitizer").

In that commit, the problem was fixed by starting gdb with -quiet, but using
that would mean the "GNU gdb (GDB) $version" line that we're trying to check
would disappear.

Fix this instead by updating the regexp to allow the message.

Tested on x86_64-linux.

Automatic date update in version.in

GDB/doc: Remove indentation from `print -elements' completion example

Remove indentation from the text of the manual after the example here:

"  Completion will in some cases guide you with a suggestion of what
kind of argument an option expects.  For example:

     (gdb) print -elements <TAB><TAB>
     NUMBER     unlimited

   Here, the option expects a number (e.g., '100'), not literal
'NUMBER'.  Such metasyntactical arguments are always presented in
uppercase."

as this is a continuation of the same paragraph.

GDB/doc: Remove extraneous spaces from completion examples

Completion results are usually different when the operation is applied
to a word that is or is not followed by a space.  In some cases they are
equivalent, however a space would not be produced if completion was used
earlier on in the word processed.

However in the manual we have completion examples given using a space
that actually prevents the example from working.  E.g.:

(gdb) info bre <TAB>

(nothing) and:

(gdb) info bre <TAB><TAB>
Display all 200 possibilities? (y or n)

as it now goes on to propose the entire symbol table, while:

(gdb) info bre<TAB>
(gdb) info breakpoints

does the right thing, but is not what is shown in the manual.

In other cases an extraneous space is used that does not correspond to
the actual completion pattern shown, which gives an impression of
sloppiness.

Remove extraneous spaces then from completion examples as appropriate.

Add newline to the end of the rnglists displsy.

Automatic date update in version.in

GDB: Add `NUMBER' completion to `set' integer commands

Fix a completion consistency issue with `set' commands accepting integer
values and the special `unlimited' keyword:

(gdb) complete print -elements
print -elements NUMBER
print -elements unlimited
(gdb)

vs:

(gdb) complete set print elements
set print elements unlimited
(gdb)

(there is a space entered at the end of both commands, not shown here)
which also means if you strike <Tab> with `set print elements ' input,
it will, annoyingly, complete to `set print elements unlimited' right
away rather than showing a choice between `NUMBER' and `unlimited'.

Add `NUMBER' then as an available completion for such `set' commands:

(gdb) complete set print elements
set print elements NUMBER
set print elements unlimited
(gdb)

Adjust the testsuite accordingly.  Also document the feature in the
Completion section of the manual in addition to the Command Options
section already there.

gdb/testsuite: Expand gdb.cp/mb-ctor.exp to test dynamic allocation

When testing GDB's ability to stop in constructors, gdb.cp/mb-ctor.exp
only tested objects allocated on the stack. This commit adds a couple of
dynamic allocations and tests if GDB can stop in it as well.

Fix implementation of readelf's -wE and -wN options,

* dwarf.c (dwarf_select_sections_by_name): If the entry's value is
zero then clear the corresponding variable.
(dwarf_select_sections_by_letters): Likewise.
* testsuite/binutils-all/debuginfo.exp: Expect -WE and -wE
debuginfod tests to fail.

[gdb] Block SIGTERM in worker threads

With gdb build with gcc-12 and -fsanitize=thread, and test-case
gdb.base/gdb-sigterm.exp, I run into:
...
WARNING: ThreadSanitizer: data race (pid=9722)^M
  Write of size 4 at 0x00000325bc68 by thread T1:^M
  #0 handle_sigterm(int) src/gdb/event-top.c:1211 (gdb+0x8ec01f)^M
  ...
  Previous read of size 4 at 0x00000325bc68 by main thread:^M
    [failed to restore the stack]^M
^M
  Location is global 'sync_quit_force_run' of size 4 at \
  0x00000325bc68 (gdb+0x325bc68)^M
  ...
SUMMARY: ThreadSanitizer: data race gdb/event-top.c:1211 in \
  handle_sigterm(int)^M
...
and 3 more data races involving handle_sigterm and locations:
- active_ext_lang
- quit_flag
- heap block of size 40
  (XNEW (async_signal_handler) in create_async_signal_handler)

This was reported in PR29297.

The testcase executes a "kill -TERM $gdb_pid", which generates a
process-directed signal.

A process-directed signal can be delivered to any thread, and what we see
here is the fallout of the signal being delivered to a worker thread rather
than the main thread.

Fix this by blocking SIGTERM in the worker threads.

[ I have not been able to reproduce this after it occurred for the first time,
so unfortunately I cannot confirm that the patch fixes the problem. ]

Tested on x86_64-linux, with and without -fsanitize=thread.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29297

gdb/doc: fix column widths in MI compatibility table

In passing I noticed that the column headings for the table of MI
compatibility and breaking changes, were overlapping, at least when
the PDF is generated on my machine.

I propose giving slightly more space to the two version number
columns, this prevents the headers overlapping for me.

Automatic date update in version.in

Fix GDBserver regression due to change to avoid reading shell registers

Simon reported that the recent change to make GDB and GDBserver avoid
reading shell registers caused a GDBserver regression, caught with
ASan while running gdb.server/non-existing-program.exp:

 $ /home/smarchi/build/binutils-gdb/gdb/testsuite/../../gdb/../gdbserver/gdbserver stdio non-existing-program
 =================================================================
 ==127719==ERROR: AddressSanitizer: heap-use-after-free on address 0x60f0000000e9 at pc 0x55bcbfa301f4 bp 0x7ffd238a7320 sp 0x7ffd238a7310
 WRITE of size 1 at 0x60f0000000e9 thread T0
     #0 0x55bcbfa301f3 in scoped_restore_tmpl<bool>::~scoped_restore_tmpl() /home/smarchi/src/binutils-gdb/gdbserver/../gdbsupport/scoped_restore.h:86
     #1 0x55bcbfa2ffe9 in post_fork_inferior(int, char const*) /home/smarchi/src/binutils-gdb/gdbserver/fork-child.cc:120
     #2 0x55bcbf9c9199 in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:991
     #3 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941
     #4 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084
     #5 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2)
     #6 0x55bcbf8ef2bd in _start (/home/smarchi/build/binutils-gdb/gdbserver/gdbserver+0x1352bd)

 0x60f0000000e9 is located 169 bytes inside of 176-byte region [0x60f000000040,0x60f0000000f0)
 freed by thread T0 here:
     #0 0x7ff9d6c6f0c7 in operator delete(void*) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:160
     #1 0x55bcbf910d00 in remove_process(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/inferiors.cc:164
     #2 0x55bcbf9c4ac7 in linux_process_target::remove_linux_process(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:454
     #3 0x55bcbf9cdaa6 in linux_process_target::mourn(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:1599
     #4 0x55bcbf988dc4 in target_mourn_inferior(ptid_t) /home/smarchi/src/binutils-gdb/gdbserver/target.cc:205
     #5 0x55bcbfa32020 in startup_inferior(process_stratum_target*, int, int, target_waitstatus*, ptid_t*) /home/smarchi/src/binutils-gdb/gdbserver/../gdb/nat/fork-inferior.c:515
     #6 0x55bcbfa2fdeb in post_fork_inferior(int, char const*) /home/smarchi/src/binutils-gdb/gdbserver/fork-child.cc:111
     #7 0x55bcbf9c9199 in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:991
     #8 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941
     #9 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084
     #10 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2)

 previously allocated by thread T0 here:
     #0 0x7ff9d6c6e5a7 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
     #1 0x55bcbf910ad0 in add_process(int, int) /home/smarchi/src/binutils-gdb/gdbserver/inferiors.cc:144
     #2 0x55bcbf9c477d in linux_process_target::add_linux_process_no_mem_file(int, int) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:425
     #3 0x55bcbf9c8f4c in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:985
     #4 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941
     #5 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084
     #6 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2)

Above we see that in the non-existing-program case, the process gets
deleted before the starting_up flag gets restored to false.

This happens because startup_inferior calls target_mourn_inferior
before throwing an error, and in GDBserver, unlike in GDB, mourning
deletes the process.

Fix this by not using a scoped_restore to manage the starting_up flag,
since we should only clear it when startup_inferior doesn't throw.

Change-Id: I67325d6f81c64de4e89e20e4ec4556f57eac7f6c

GDB/testsuite: Tighten `set print elements' error check

Match the whole error message expected to be given rather than omitting
the part about the "unlimited" keyword.  There's no point in omitting
the missing part first, and second with an upcoming change the part in
parentheses will no longer be a fixed string, so doing a full match will
ensure the algorithm correctly builds the message expected here.  Also
avoid any wildcard matches.

GDB: Remove extraneous full stops from `set' command error messages

With errors given for bad commands such as `set annotate' or `set width'
we produce an extraneous full stop within parentheses:

(gdb) set annotate
Argument required (integer to set it to.).
(gdb) set width
Argument required (integer to set it to, or "unlimited".).
(gdb)

This is grammatically incorrect, so remove the full stop and adjust the
testsuite accordingly.

gdb/doc: improve description of --data-disassemble opcodes output

Extend the description of the MI command --data-disassemble.
Specifically, expand the description of the 'opcodes' field to explain
how the bytes are formatted.

gdb/arm: Only stack S16..S31 when FPU registers are secure

The FPCCR.TS bit is used to identify if FPU registers are considered
non-secure or secure.  If they are secure, then callee saved registers
(S16 to S31) are stacked on exception entry or otherwise skipped.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>

opcodes/aarch64: split off creation of comment text in disassembler

The function aarch64_print_operand (aarch64-opc.c) is responsible for
converting an instruction operand into the textual representation of
that operand.

In some cases, a comment is included in the operand representation,
though this (currently) only happens for the last operand of the
instruction.

In a future commit I would like to enable the new libopcodes styling
for AArch64, this will allow objdump and GDB[1] to syntax highlight
the disassembler output, however, having operands and comments
combined in a single string like this makes such styling harder.

In this commit, I propose to extend aarch64_print_operand to take a
second buffer.  Any comments for the instruction are written into this
extra buffer.  The two callers of aarch64_print_operand are then
updated to pass an extra buffer, and print any resulting comment.

In this commit no styling is added, that will come later.  However, I
have adjusted the output slightly.  Before this commit some comments
would be separated from the instruction operands with a tab character,
while in other cases the comment was separated with two single spaces.

After this commit I use a single tab character in all cases.  This
means a few test cases needed updated.  If people would prefer me to
move everyone to use the two spaces, then just let me know.  Or maybe
there was a good reason why we used a mix of styles, I could probably
figure out a way to maintain the old output exactly if that is
critical.

Other than that, there should be no user visible changes after this
commit.

[1] GDB patches have not been merged yet, but have been posted to the
GDB mailing list:
https://sourceware.org/pipermail/gdb-patches/2022-June/190142.html

gdb/testsuite: fix gdb.base/break-idempotent.exp on ppc

When running the gdb.base/break-idempotent.exp test on ppc, I was
seeing some test failures (or rather errors), that looked like this:

  (gdb) watch local
  Hardware watchpoint 2: local

  has_hw_wp_support: Hardware watchpoint detected
  ERROR: no fileid for gcc2-power8
  ERROR: Couldn't send delete breakpoints to GDB.
  ERROR OCCURED: can't read "gdb_spawn_id": no such variable
      while executing
  "expect {
  -i 1000 -timeout 100
          -re ".*A problem internal to GDB has been detected" {
              fail "$message (GDB internal error)"
              gdb_internal_erro..."
      ("uplevel" body line 1)
      invoked from within

What happens is that in break-idempotent.exp we basically do this:

    if {[prepare_for_testing "failed to prepare" $binfile $srcfile $opts]} {
        continue
    }

    # ....

    if {![skip_hw_watchpoint_tests]} {
        test_break $always_inserted "watch"
    }

The problem with this is that skip_hw_watchpoint_tests, includes this:

    if { [istarget "i?86-*-*"]
 || [istarget "x86_64-*-*"]
 || [istarget "ia64-*-*"]
 || [istarget "arm*-*-*"]
 || [istarget "aarch64*-*-*"]
 || ([istarget "powerpc*-*-linux*"] && [has_hw_wp_support])
 || [istarget "s390*-*-*"] } {
return 0
    }

For powerpc only we call has_hw_wp_support.  This is a caching proc
that runs a test within GDB to detect if we have hardware watchpoint
support or not.

Unfortunately, to run this test we restart GDB, and when the test has
completed, we exit GDB.  This means that in break-idempotent.exp, when
we call skip_hw_watchpoint_tests for the first time on powerpc, GDB
will unexpectedly be exited.  When we later call delete_breakpoints we
see the errors I reported above.

The fix is to call skip_hw_watchpoint_tests early, before we start GDB
as part of the break-idempotent.exp script, and store the result in a
variable, we can then check this variable in the script as needed.

After this change break-idempotent.exp runs fine on powerpc.

Co-authored-by: Andrew Burgess <aburgess@redhat.com>

x86: drop stray NoRex64 from XBEGIN

Presumably this being there was a result of taking CALL as a reference
when adding the RTM insns. But with No_qSuf the attribute has no effect.

gprofng: fix build when BUILD_MAN is false

gprofng/ChangeLog
2022-06-28  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29131
* gp-display-html/Makefile.am: Set man_MANS only when BUILD_MAN is true.
* src/Makefile.am: Likewise.
* gp-display-html/Makefile.in: Rebuild.
* src/Makefile.in: Rebuild.

gprofng: use $(sysconfdir) instead $(prefix)/etc

gprofng/ChangeLog
2022-06-28  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29191
* src/Makefile.am: Use $(sysconfdir) instead $(prefix)/etc.
* src/Settings.cc: Likewise.
* src/Makefile.in: Rebuild.

Re: ld/x86: skip p_align-1 tests with unsuitable compiler

commit d0e0f9c87a3e results "ERROR: i586-linux-cc does not exist" if
cross-building an i586-linux target without a target compiler
installed.

* testsuite/ld-elf/linux-x86.exp (compiler_honours_aligned): New.
Use it after first testing check_compiler_available.

Automatic date update in version.in

gdb+gdbserver/Linux: avoid reading registers while going through shell

For every stop, Linux GDB and GDBserver save the stopped thread's PC,
in lwp->stop_pc.  This is done in save_stop_reason, in both
gdb/linux-nat.c and gdbserver/linux-low.cc.  However, while we're
going through the shell after "run", in startup_inferior, we shouldn't
be reading registers, as we haven't yet determined the target's
architecture -- the shell's architecture may not even be the same as
the final inferior's.

In gdb/linux-nat.c, lwp->stop_pc is only needed when the thread has
stopped for a breakpoint, and since when going through the shell, no
breakpoint is going to hit, we could simply teach save_stop_reason to
only record the stop pc when the thread stopped for a breakpoint.

However, in gdbserver/linux-low.cc, lwp->stop_pc is used in more cases
than breakpoint hits (e.g., it's used in tracepoints & the
"while-stepping" feature).

So to avoid GDB vs GDBserver divergence, we apply the same approach to
both implementations.

We set a flag in the inferior (process in GDBserver) whenever it is
being nursed through the shell, and when that flag is set,
save_stop_reason bails out early.  While going through the shell,
we'll only ever get process exits (normal or signalled), random
signals, and exec events, so nothing is lost.

Change-Id: If0f01831514d3a74d17efd102875de7d2c6401ad

[gdb/build] Fix gdb build with -fsanitize=thread and gcc 7

When building gdb with system gcc 7.5.0, I run into:
...
gdb/ia64-tdep.c: In function ‘int is_float_or_hfa_type_recurse(type*, type**)’:
gdb/ia64-tdep.c:3362:1: error: control reaches end of non-void function \
  [-Werror=return-type]
...

This is due to PR gcc/81275 - "-fsanitize=thread produce incorrect
-Wreturn-type warning", which has been fixed in gcc-8.

Work around this by moving the default return outside the switch.

Tested on x86_64-linux.

bfd: handle codepage when opening files on MinGW

Even if MS docs say that CP_UTF8 should always be used on newer
applications, forcing it might produce undefined filename if the
encoding isn't UTF-8.
MinGW seems to call ___lc_codepage_func() in order to retrieve the
current thread codepage.

bfd/ChangeLog:

        * bfdio.c (_bfd_real_fopen): Retrieve codepage with
        ___lc_codepage_func() on MinGW.

windres: add quotes around preprocessor cmd if needed

This patch ensures that the gcc binary called by windres is quoted if
needed. Otherwise, errors can occur if the gcc is under a folder having
a name containing a space (eg "Program Files").

binutils/
* resrc.c (DEFAULT_PREPROCESSOR): Split into...
(DEFAULT_PREPROCESSOR_CMD): that...
(DEFAULT_PREPROCESSOR_ARGS): and that.
(look_for_default): Add quotes around the command if needed.
(read_rc_file): Adapt to new defines.

Fix the display of the idnex values for DW_FORM_loclistx and DW_FORM_rnglistx.  Correct the display of .debug.loclists sections.

PR 29267
* dwarf.c (display_debug_rnglists): New function, broken out of..
(display_debug_ranges): ... here.
(read_and_display_attr_value): Correct calculation of index
displayed for DW_FORM_loclistx and DW_FORM_rnglistx.
* testsuite/binutils-all/x86-64/pr26808.dump: Update expected
output.

ld/x86: skip p_align-1 tests with unsuitable compiler

When the compiler doesn't properly arrange for foo's alignment, there's
no point even trying these tests. Report the situation as a single
"unsupported" test.

PowerPC64: align plt_branch stubs

plt_branch stubs are similar to plt_call stubs in that they branch
via bctr.  Align them too.

bfd/
* elf64-ppc.c (ppc_size_one_stub): Align plt_branch stubs as for
plt_call stubs.
ld/
* testsuite/ld-powerpc/elfv2exe.d: Adjust for plt_branch changes.
* testsuite/ld-powerpc/notoc.d: Likewise.
* testsuite/ld-powerpc/notoc.wf: Likewise.
* testsuite/ld-powerpc/notoc3.d: Likewise.
* testsuite/ld-powerpc/pr23937.d: Likewise.

PowerPC64: plt_stub_pad

* elf64-ppc.c (plt_stub_pad): Simplify parameters and untangle
from plt_stub_size.
(ppc_size_one_stub): Call plt_stub_size before plt_stub_pad to
provide size.  Recalculate size if it might change.

PowerPC64: Tidy stub type changes

It made sense before I started using separate fields for main type and
sub type to add a difference in main type to the type (thus keeping
sub type unchanged).  Not so much now.

* elf64-ppc.c (ppc_merge_stub): Simplify stub type change.
(ppc_size_one_stub): Likewise.

gdb:csky add pseudo regs for float and vector regs

In the existing CSKY architecture, there are at most 32 floating
and 16 vector registers. Float registers's count can be configured
as 16 or 32. In the future, the vector registers's count may be
extended to 32.

The bit width of floating-point register is 64bits, and the bit
width of vector register is 128bit.

Special points: in fr0~fr15 and vr0~vr15, each FRx is the lower
64 bits of the corresponding VRx.

Here, we will split each floating-point and vector register to
32bits wide, add the corresponding pseudo registers, and finally
use them for the dwarf registers.

There are 128 pseudo registers in total, s0~s127, including:
1. s0 and s1 correspond to fr0, s4 and s5 correspond to fr1, and so on.
Every two separated pseudo registers correspond to a float register.
2. s0, s1, s2 and s3 correspond to vr0; s4, s5, s6 and s7 correspond to vr1,
and so on. Every four pseudo registers corresponds to a vector register.

Therefore, in s64~s127, there are general registers that are not actually
used. This part is to prepare for the expansion of vector registers to 32

Therefore, in s64~s127, half of the registers are actually unused. This
part is to prepare for the expansion of the vector register to 32.

PR29293, elfnn-aarch64.c: def_protected member unintialized

PR 29293
* elfnn-aarch64.c (elfNN_aarch64_link_hash_newfunc): Init def_protected.

RISC-V: Add 'Sstc' extension and its CSRs

This commit adds "stimecmp / vstimecmp" Extension (Sstc) and its CSRs.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Sstc'
extension to valid 'S' extension list.

gas/ChangeLog:

* config/tc-riscv.c (enum riscv_csr_class): Add CSR classes for
'Sstc' extension. (riscv_csr_address): Add handling for new CSR
classes.
* testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs.
* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
* testsuite/gas/riscv/csr.s: Add new CSRs.
* testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.

include/ChangeLog:

* opcode/riscv-opc.h (CSR_STIMECMP, CSR_STIMECMPH,
CSR_VSTIMECMP, CSR_VSTIMECMPH): New CSR macros.

RISC-V: Add 'Sscofpmf' extension with its CSRs

This commit adds Count Overflow and Mode-Based Filtering Extension
(Sscofpmf) and its CSRs.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Sscofpmf'
extension to valid 'S' extension list.

gas/ChangeLog:

* config/tc-riscv.c (enum riscv_csr_class): Add CSR classes for
'Sscofpmf' extension. (riscv_csr_address): Add handling for new
CSR classes.
* testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs.
* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
* testsuite/gas/riscv/csr.s: Add new CSRs.
* testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.

include/ChangeLog:

* opcode/riscv-opc.h (CSR_SCOUNTOVF, CSR_MHPMEVENT3H,
CSR_MHPMEVENT4H, CSR_MHPMEVENT5H, CSR_MHPMEVENT6H,
CSR_MHPMEVENT7H, CSR_MHPMEVENT8H, CSR_MHPMEVENT9H,
CSR_MHPMEVENT10H, CSR_MHPMEVENT11H, CSR_MHPMEVENT12H,
CSR_MHPMEVENT13H, CSR_MHPMEVENT14H, CSR_MHPMEVENT15H,
CSR_MHPMEVENT16H, CSR_MHPMEVENT17H, CSR_MHPMEVENT18H,
CSR_MHPMEVENT19H, CSR_MHPMEVENT20H, CSR_MHPMEVENT21H,
CSR_MHPMEVENT22H, CSR_MHPMEVENT23H, CSR_MHPMEVENT24H,
CSR_MHPMEVENT25H, CSR_MHPMEVENT26H, CSR_MHPMEVENT27H,
CSR_MHPMEVENT28H, CSR_MHPMEVENT29H, CSR_MHPMEVENT30H,
CSR_MHPMEVENT31H): New CSR macros.

RISC-V: Add 'Smstateen' extension and its CSRs

This commit adds State Enable Extension (Smstateen) and its CSRs.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Smstateen'
extension to valid 'S' extension list.

gas/ChangeLog:

* config/tc-riscv.c (enum riscv_csr_class): Add CSR classes for
'Smstateen' extension. (riscv_csr_address): Add handling for
new CSR classes.
* testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs.
* testsuite/gas/riscv/csr-dw-regnums.d: Likewise.
* testsuite/gas/riscv/csr.s: Add new CSRs.
* testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.

include/ChangeLog:

* opcode/riscv-opc.h (CSR_MSTATEEN0, CSR_MSTATEEN1,
CSR_MSTATEEN2, CSR_MSTATEEN3, CSR_SSTATEEN0, CSR_SSTATEEN1,
CSR_SSTATEEN2, CSR_SSTATEEN3, CSR_HSTATEEN0, CSR_HSTATEEN1,
CSR_HSTATEEN2, CSR_HSTATEEN3, CSR_MSTATEEN0H, CSR_MSTATEEN1H,
CSR_MSTATEEN2H, CSR_MSTATEEN3H, CSR_HSTATEEN0H, CSR_HSTATEEN1H,
CSR_HSTATEEN2H, CSR_HSTATEEN3H): New CSR macros.

RISC-V: Add new CSR feature gate handling (RV32,H)

To support feature gate like Smstateen && H, this commit adds certain
CSR feature gate handling.  It also changes how RV32-only CSRs are
handled for cleanliness.

gas/ChangeLog:

* config/tc-riscv.c (riscv_csr_address): Add CSR feature gate
handling for H.  Change handling on RV32.

Re: Disable execstack and rwx segments warnings for MIPS targets.

PR 29263
* configure.ac: Fix typo.
* testsuite/ld-elf/elf.exp: Add mips to targets that need
--warn-execstack to pass first pr29072 test.

Automatic date update in version.in

gdb/testsuite: update bug numbers from Gnats to bugzilla

Some tests link to outdated bug numbers when an XFAIL or a KFAIL happen.

gdb.base/macscp.exp was referencing bug number 555, and the bug 7660
mentions that it used to be 555 on the Gnats system and seems to relate
to the issue at hand.

gdb.base/annota1.exp was referencing bug number 1270, and bug 8375
mentions being number 1270 on Gnats, and mentions annota1 specifically,
so it seemed pretty obvious.

[gdb/build] Fix build breaker with --enable-shared

When building gdb with --enable-shared, I run into:
...
ld: build/zlib/libz.a(libz_a-inffast.o): relocation R_X86_64_32S against \
  `.rodata' can not be used when making a shared object; recompile with -fPIC
ld: build/zlib/libz.a(libz_a-inflate.o): warning: relocation against \
  `inflateResetKeep' in read-only section `.text'
collect2: error: ld returned 1 exit status
make[3]: *** [libbfd.la] Error 1
...

This is a regression since commit a08bdb159bb ("[gdb/build] Fix gdbserver
build with -fsanitize=thread").

The problem is that a single case statement in configure is shared to handle
special requirements for both the host libiberty and host zlib, which has the
effect that only one is handled.

Fix this by handling libiberty and zlib each in its own case statement.

Build on x86_64-linux, with and without --enable-shared.

ChangeLog:

2022-06-27  Tom de Vries  <tdevries@suse.de>

* configure.ac: Set extra_host_libiberty_configure_flags and
extra_host_zlib_configure_flags in separate case statements.
* configure: Regenerate.

Make GDBserver abort on internal error in development mode

Currently, if GDBserver hits some internal assertion, it exits with
error status, instead of aborting.  This makes it harder to debug
GDBserver, as you can't just debug a core file if GDBserver fails an
assertion.  I've had to hack the code to make GDBserver abort to debug
something several times before.

I believe the reason it exits instead of aborting, is to prevent
potentially littering the filesystem of smaller embedded targets with
core files.  I think I recall Daniel Jacobowitz once saying that many
years ago, but I can't be sure.  Anyhow, that seems reasonable to me.

Since we nowadays have a distinction between development and release
modes, I propose to make GDBserver abort on internal error if in
development mode, while keeping the status quo when in release mode.

Thus, after this patch, in development mode, you get:

 $ ../gdbserver/gdbserver
 ../../src/gdbserver/server.cc:3711: A problem internal to GDBserver has been detected.
 captured_main: Assertion `0' failed.
 Aborted (core dumped)
 $

while in release mode, you'll continue to get:

 $ ../gdbserver/gdbserver
 ../../src/gdbserver/server.cc:3711: A problem internal to GDBserver has been detected.
 captured_main: Assertion `0' failed.
 $ echo $?
 1

I do not think that this requires a separate configure switch.

A "--target_board=native-extended-gdbserver" run on Ubuntu 20.04 ends
up with:

 === gdb Summary ===

 # of unexpected core files      29
 ...

for me, of which 8 are GDBserver core dumps, 7 more than without this
patch.

Change-Id: I6861e08ad71f65a0332c91ec95ca001d130b0e9d

Replace a run-time assertion failure with a warning message when parsing corrupt DWARF data.

PR 29289
* dwarf.c (display_debug_names): Replace assert with a warning
message.

Fix NULL pointer indirection when parsing corrupt DWARF data.

PR 29290
* dwarf.c (read_and_display_attr_value): Check that debug_info_p
is set before dereferencing it.

Have gold's File_read::do_read() function check the start parameter

PR 23765
* fileread.cc (File_read::do_read): Check start parameter before
computing number of bytes to read.

gdb/arm: Unwind Non-Secure callbacks from Secure

Without this changeset, the unwinding doesn't take into account
Non-Secure to Secure stack unwinding enablement status and
doesn't choose the proper SP to do the unwinding.

This patch only unwinds the stack when Non-Secure to Secure
unwinding is enabled, previous SP is set w/r to the current mode
(Handler -> msp_s, Thread -> psp_s) and then the Secure stack is
unwound.  Ensure thumb bit is set in PSR when needed.  Also, drop
thumb bit from PC if set.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan ROUX <yvan.roux@foss.st.com>

Stop bogus warnings about DWARF indexed string offsets being too big.

* dwarf.c (fetch_indexed_string): Do not use length of first table
in string section as the length of every table in the section.
* testsuite/binutils-all/pr26112.r: Update expected output.

[gdb/testsuite] Handle older python in gdb.python/py-send-packet.py

With python 3.4, I run into:
...
Traceback (most recent call last):^M
  File "<string>", line 1, in <module>^M
  File
  "outputs/gdb.python/py-send-packet/py-send-packet.py", line 128, in \
    run_set_global_var_test^M
    res = conn.send_packet(b"X%x,4:\x02\x02\x02\x02" % addr)^M
TypeError: Could not convert Python object: b'X%x,4:\x02\x02\x02\x02'.^M
Error while executing Python code.^M
...
while with python 3.6 this works fine.

The type of addr is <class 'gdb.Value'>, so the first thing to try is whether
changing it into a string works:
...
    addr_str = "%x" % addr
    res = conn.send_packet(b"X%s,4:\x02\x02\x02\x02" % addr_str)
...
which gets us the more detailed:
...
TypeError: unsupported operand type(s) for %: 'bytes' and 'str'
...

Fix this by avoiding the '%' operator in the byte literal, and use instead:
...
def xpacket_header (addr):
    return ("X%x,4:" % addr).encode('ascii')
  ...
    res = conn.send_packet(xpacket_header(addr) + b"\x02\x02\x02\x02")
...

Tested on x86_64-linux, with python 3.4 and 3.6, and a backported version was
tested on the gdb-12-branch in combination with python 2.7.

[gdb/testsuite] Fix gdb.reverse/i387-env-reverse.exp for -pie

When running test-case gdb.reverse/i387-env-reverse.exp for x86_64-linux with
target board unix/-m32/-fPIE/-pie, we run into:
...
(gdb) PASS: gdb.reverse/i387-env-reverse.exp: push st0
info register eax^M
eax            0x56550000          1448411136^M
(gdb) FAIL: gdb.reverse/i387-env-reverse.exp: verify eax == 0x8040000
...

The problem is that the tested instruction (fstsw) only sets $ax, not $eax.

Fix this by verifying $ax instead of $eax.

Tested on x86_64-linux with target boards unix/-m32 and unix/-m32/-fPIE/-pie.

[gdb/testsuite] Enable some test-cases for x86_64 -m32

When trying to run test-case gdb.reverse/i387-env-reverse.exp for x86_64-linux
with target board unix/-m32, it's skipped.

Fix this by using is_x86_like_target instead of istarget "i?86-*linux*".

This exposes a number of duplicates, fix those by making the test names unique.

Likewise in a couple of other test-cases.

Tested on x86_64-linux with target boards unix/-m32.

[gdb/testsuite] Workaround unnecessary .s file with gfortran 4.8

After running test-case gdb.fortran/namelist.exp with gfortran 4.8.5, I'm left
with:
...
$ git sti
On branch master
Your branch is up to date with 'origin/master'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        gdb/testsuite/lib/compiler.s

nothing added to commit but untracked files present (use "git add" to track)
...

We're running into PR gcc/60447, which was fixed in gcc 4.9.0.

Workaround this by first copying the source file to the temp dir, such that
the .s file is left there instead:
...
$ ls build/gdb/testsuite/temp/<runtest pid>/
compiler.c  compiler.F90  compiler.s
...

Tested on x86_64-linux.

[gdb/testsuite] Skip gdb.fortran/namelist.exp for gfortran 4.8

The test-case gdb.fortran/namelist.exp uses a gfortran feature (emitting
DW_TAG_namelist in the debug info) that has been supported since gfortran 4.9,
see PR gcc/37132.

Skip the test for gfortran 4.8 and earlier.  Do this using gcc_major_version,
and update it to be able to handle "gcc_major_version {gfortran-*} f90".

Tested on x86_64-linux, with gfortran 4.8.5, 7.5.0, and 12.1.1.

[gdb/symtab] Fix parsing of .debug_str_offsets header

When running test-case gdb.dwarf2/fission-mix.exp with target board dwarf64
and gcc-12 (defaulting to DWARF5), I run into:
...
(gdb) break func2^M
Offset from DW_FORM_GNU_str_index or DW_FORM_strx pointing outside of \
  .debug_str.dwo section in CU at offset 0x0 [in module fission-mix]^M
(gdb) FAIL: gdb.dwarf2/fission-mix.exp: break func2
...

The .debug_str_offsets section has version 5, so as per the standard it has
it's own header, with initial length and version:
...
Contents of the .debug_str_offsets.dwo section (loaded from fission-mix2.dwo):

    Length: 0x1c
    Version: 0x5
       Index   Offset [String]
           0        0 build/gdb/testsuite
           1       33 GNU C17
           2       8f src/gdb/testsuite/gdb.dwarf2/fission-mix-2.c
...

But when trying to read the string offset at index 0 in the table (which
is 0), we start reading at offset 8, which points in the header, at the last
4 bytes of the initial length (it's 12 bytes because of 64-bit dwarf), as well
at the 2-byte version field and 2 bytes of padding, so we get:
...
(gdb) p /x str_offset
$1 = 0x500000000
...
which indeed is an offset that doesn't fit in the .debug_str section.

The offset 8 is based on reader->cu->header.addr_size:
...
static const char *
read_dwo_str_index (const struct die_reader_specs *reader, ULONGEST str_index)
{
 ULONGEST str_offsets_base = reader->cu->header.version >= 5
                             ? reader->cu->header.addr_size : 0;
...
which doesn't in look in agreement with the standard.

Note that this happens to give the right answer for 32-bit dwarf and
addr_size == 8, because then we have header size ==
(initial length (4) + version (2) + padding (2)) == 8.

Conversely, for 32-bit dwarf and addr_size == 4 (target board unix/-m32)
we run into a similar problem.  It just happens to not trigger the warning,
instead we get the wrong strings, like "func2" for DW_AT_producer and
"build/gdb/testsuite" for DW_AT_name of the DW_TAG_compile_unit DIE.

Fix this by parsing the .debug_str_offsets header in read_dwo_str_index.

Add a FIXME that we should not parse this for every call.

Tested on x86_64-linux.

[gdb/build] Fix gdbserver build with -fsanitize=thread

[ Copied from gcc commit 153689603fd ("[gdb/build] Fix gdbserver build with
-fsanitize=thread"). ]

When building gdbserver with -fsanitize=thread (added to CFLAGS/CXXFLAGS) we
run into:
...
ld: ../libiberty/libiberty.a(safe-ctype.o): warning: relocation against \
  `__tsan_init' in read-only section `.text'
ld: ../libiberty/libiberty.a(safe-ctype.o): relocation R_X86_64_PC32 \
  against symbol `__tsan_init' can not be used when making a shared object; \
  recompile with -fPIC
ld: final link failed: bad value
collect2: error: ld returned 1 exit status
make[1]: *** [libinproctrace.so] Error 1
...
which looks similar to what is described in commit 78e49486944 ("[gdb/build]
Fix gdbserver build with -fsanitize=address").

The gdbserver component builds a shared library libinproctrace.so, which uses
libiberty and therefore requires the pic variant.  The gdbserver Makefile is
setup to use this variant, if available, but it's not there.

Fix this by listing gdbserver in the toplevel configure alongside libcc1, as a
component that needs the libiberty pic variant, setting:
...
extra_host_libiberty_configure_flags=--enable-shared
...

Tested on x86_64-linux.

ChangeLog:

2022-06-27  Tom de Vries  <tdevries@suse.de>

* configure.ac: Build libiberty pic variant for gdbserver.
* configure: Regenerate.

Disable execstack and rwx segments warnings for MIPS targets.

PR 29263
* configure.ac: Move HPPA specific code from here...
* configure.tgt: ... to here.  Add similar code for MIPS.
Move code for CRIS, MIPS and HPPA to block at start of file.
* configure: Regenerate.

bfd: prune config.bfd's setting of targ_archs

The final "match all" case can take care of a few explicit entries:
Purge those. Also move s12z* into proper position (the table is
otherwise sorted, after all).

drop XC16x bits

Commit 04f096fb9e25 ("Move the xc16x target to the obsolete list") moved
the architecture from the "obsolete but still available" to the
"obsolete / support removed" list in config.bfd, making the architecture
impossible to enable (except maybe via "enable everything" options").

Note that I didn't touch */po/*.po{,t} on the assumption that these
would be updated by some (half)automatic means.

Fix location list offset address dump under DW_AT_location (dwarf-5)

For clang compiled objects with dwarf-5, location list offset address dump
under DW_AT_location is corrected, where DW_FORM_loclistx is used. While
dumping the location list offset, the address dumped is wrong where it was
refering to .debug_addr instead of .debug_loclists

      * dwarf.c (fetch_indexed_value): Add base_address as parameter and
      use it to access the section offset.
      (read_and_display_attr_value): Handle DW_FORM_loclistx form separately.
      Pass loclists_base to fetch_indexed_value().

PowerPC64 .branch_lt address

.branch_lt is really an extension of .plt, as is .iplt.  We'd like all
of the PLT sections to be fixed relative to .TOC. after stub sizing,
because changes in offset to PLT entries might mean a change in stub
sizes.  When -z relro, the relro layout does this by laying out
sections from the end of the relro segment.  So for example, a change
in .eh_frame (which happens after stub sizing) will keep the same GOT
to PLT offset when -z relro.  Not so when -z norelro, because then the
usual forward layout of section is done and .got is more aligned than
.branch_lt.

* emulparams/elf64ppc.sh: Set .branch_lt address fixed relative
to .got.
* testsuite/ld-powerpc/elfv2exe.d: Adjust to suit.

-z relro relaxation and ld script SIZEOF

A number of targets use assignments like:
. = DATA_SEGMENT_RELRO_END (SIZEOF (.got.plt) >= 12 ? 12 : 0, .);
(from i386) in linker scripts to put the end of the relro segment past
the header in .got.plt.  Examination of testcases like those edited by
this patch instead sees the end of the relro segment being placed at
the start of .got.plt.  For the i386 pie1 test:

  [ 9] .got.plt          PROGBITS        00002000 001000 00000c 04  WA  0   0  4

  GNU_RELRO      0x000f90 0x00001f90 0x00001f90 0x00070 0x00070 R   0x1

A map file shows:

.dynamic        0x0000000000001f90       0x70
 *(.dynamic)
 .dynamic       0x0000000000001f90       0x70 tmpdir/pie1.o
                0x0000000000001f90                _DYNAMIC

.got            0x0000000000002000        0x0
 *(.got)
 .got           0x0000000000002000        0x0 tmpdir/pie1.o
 *(.igot)
                0x0000000000002ff4                . = DATA_SEGMENT_RELRO_END (., (SIZEOF (.got.plt) >= 0xc)?0xc:0x0)

.got.plt        0x0000000000002000        0xc
 *(.got.plt)
 .got.plt       0x0000000000002000        0xc tmpdir/pie1.o
                0x0000000000002000                _GLOBAL_OFFSET_TABLE_

The DATA_SEGMENT_RELRO_END value in the map file is weird too.  All of
this is triggered by SIZEOF (.got.plt) being evaluated wrongly as
zero.  Fix it by taking into account the action of
lang_reset_memory_regions during relaxation.

* ldexp.c (fold_name <SIZEOF>): Use rawsize if size has been reset.
* ldlang.c (lang_size_sections_1): Don't reset processed_vma here.
* testsuite/ld-i386/pie1.d: Adjust to suit.
* testsuite/ld-x86-64/pr20830a.d: Likewise.
* testsuite/ld-x86-64/pr20830b.d: Likewise.
* testsuite/ld-x86-64/pr21038a.d: Likewise.
* testsuite/ld-x86-64/pr21038b.d: Likewise.
* testsuite/ld-x86-64/pr21038c.d: Likewise.

Automatic date update in version.in

Automatic date update in version.in

arm: Define elf_backend_extern_protected_data to 0 [PR 18705]

Similar to commit 4fb55bf6a9606eb7b626c30a9f4e71d6c2d4fbb2 for aarch64.

Commit b68a20d6675f1360ea4db50a9835c073675b9889 changed ld to produce
R_ARM_GLOB_DAT but that defeated the purpose of protected visibility
as an optimization.  Restore the previous behavior (which matches
ld.lld) by defining elf_backend_extern_protected_data to 0.

Fix corrupt DWARF in dw2-double-set-die-type

The dw2-double-set-die-type.exp test case caused an AddressSanitizer
failure in the new DWARF scanner.

The immediate cause was bad DWARF in the test -- in particular, the
the sibling attribute here:

     <2><181>: Abbrev Number: 33 (DW_TAG_subprogram)
<182>   DW_AT_external    : 1
<183>   DW_AT_name        : address
<18b>   DW_AT_type        : <0x171>
<18f>   DW_AT_declaration : 1
<190>   DW_AT_sibling     : <0x1a1>
    ...
     <1><1a1>: Abbrev Number: 23 (DW_TAG_pointer_type)
<1a2>   DW_AT_byte_size   : 4
<1a3>   DW_AT_type        : <0x1a7>

...points to a "sibling" DIE that is at a different child depth.

Because this test case doesn't really require sibling attributes, this
patch fixes the problem by removing them from the test.

Note that gdb is not generally robust against malformed DWARF.
Detecting and compensating for this problem would probably be
expensive and, IMO, is better left to some (still hypothetical) DWARF
linter.

Fix end of CU calculation in cooked_indexer::index_dies

cooked_indexer::index_dies incorrect computes the end of the current
CU in the .debug_info.  This isn't readily testable without writing
intentionally corrupt DWARF, but it's apparent through observation: it
is currently based on 'info_ptr', which does not always point to the
start of the CU.  This patch fixes the expression.  Tested on x86-64
Fedora 34.

gdb: LoongArch: Implement loongarch_linux_syscall_next_pc()

When FRAME is at a syscall instruction, return the PC of the next
instruction to be executed.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

gdb: LoongArch: Define register numbers and clean up code

This commit defines register numbers of various important registers,
we can use them directly in the related code, and also clean up some
code to make them more clear and readable.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

Automatic date update in version.in

Eliminate TUI/CLI observers duplication

For historical reasons, the CLI and the TUI observers are basically
exact duplicates, except for the downcast:

 cli:
       struct cli_interp *cli = as_cli_interp (interp);
 tui:
       struct interp *tui = as_tui_interp (interp);

and how they get at the interpreter's ui_out:

 cli:
       cli->cli_uiout
 tui:
       tui->interp_ui_out ()

Since interp_ui_out() is a virtual method that also works for the CLI
interpreter, and, both the CLI and the TUI interpreters inherit from
the same base class (cli_interp_base), we can convert the CLI
observers to cast to cli_interp_base instead and use interp_ui_out()
too.  With that, the CLI observers will work for the TUI interpreter
as well.  This lets us completely eliminate the TUI observers.  That's
what this commit does.

Change-Id: Iaf6cf12dfa200ed3ab203a895a72b69dfedbd6e0

Revert "Delete delete_thread_silent"

Turns out we'll be gaining a new use of this function very soon, the
incoming AMDGPU port needs it.  Let's add it back, as it isn't really
hurting anything.

This reverts commit 39b8a8090ed7e8967ceca3655aa5f3a2ae91219d.

gdb/arm: Update the value of active sp when base sp changes

For Arm Cortex-M33 with security extensions, there are 4 different
stacks pointers (msp_s, msp_ns, psp_s, psp_ns).
When plain "sp" is updated during unwinding of the stack, the active
stack pointer of the 4 stack pointers needs to be kept in sync.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>

gdb/testsuite: remove unneeded calls to get_compiler_info

It is not necessary to call get_compiler_info before calling
test_compiler_info, and, after recent commits that removed setting up
the gcc_compiled, true, and false globals from get_compiler_info,
there is now no longer any need for any test script to call
get_compiler_info directly.

As a result every call to get_compiler_info outside of lib/gdb.exp is
redundant, and this commit removes them all.

There should be no change in what is tested after this commit.

gdb/testsuite: remove global gcc_compiled from gdb.exp

After this commit the gcc_compiled global is no longer exported from
lib/gdb.exp.  In theory we could switch over all uses of gcc_compiled
to instead call test_compiler_info directly, however, I have instead
added a new proc to gdb.exp: 'is_c_compiler_gcc'.  I've then updated
the testsuite to call this proc instead of using the global.

Having a new proc specifically for this task means that we have a
single consistent pattern for detecting gcc.  By wrapping this logic
within a proc that calls test_compiler_info, rather than using the
global, means that test scripts don't need to call get_compiler_info
before they read the global, simply calling the new proc does
everything in one go.

As a result I've been able to remove the get_compiler_info calls from
all the test scripts that I've touched in this commit.

In some of the tests e.g. gdb.dwarf2/*.exp, the $gcc_compiled flag was
being checked at the top of the script to decide if the whole script
should be skipped or not.  In these cases I've called the new proc
directly and removed all uses of gcc_compiled.

In other cases, e.g. most of the gdb.base scripts, there were many
uses of gcc_compiled.  In these cases I set a new global gcc_compiled
near the top of the script, and leave the rest of the script
unchanged.

There should be no changes in what is tested after this commit.

Include count of unexpected core files in gdb.sum summary

If GDB, GDBserver, a testcase program, Valgrind, etc. unexpectedly
crash while running the GDB testsuite, and you've setup your machine
such that core files are dumped in the current directory instead of
being shoved somewhere by abrt, apport, or similar (as you should for
proper GDB testing), you'll end up with an unexpected core file in the
$build/gdb/testsuite/ directory.

It can happen that GDB, GDBserver, etc. even crashes _after_ gdb_exit,
during teardown, and thus such a crash won't be noticed by looking at
the gdb.sum file at all.  This commit aims at improving that, by
including a new "unexpected core files" line in the testrun summary.

For example, here's what I get on x86-64 Ubuntu 20.04, with this
patch:

 === gdb Summary ===

 # of unexpected core files      12          << new info
 # of expected passes            107557
 # of unexpected failures        35
 # of expected failures          77
 # of unknown successes          2
 # of known failures             114
 # of untested testcases         31
 # of unsupported tests          139

I have my core pattern setup like this:

 $ cat /proc/sys/kernel/core_pattern
 core.%e.%p.%h.%t

That's:

 %e: executable filename
 %p: pid
 %h: hostname
 %t: UNIX time of dump

and so I get these core files:

 $ ls -1 testsuite/core.*
 testsuite/core.connect-with-no.216191.nelson.1656002431
 testsuite/core.connect-with-no.217729.nelson.1656002431
 testsuite/core.gdb.194247.nelson.1656002423
 testsuite/core.gdb.226014.nelson.1656002435
 testsuite/core.gdb.232078.nelson.1656002438
 testsuite/core.gdb.352268.nelson.1656002441
 testsuite/core.gdb.4152093.nelson.1656002337
 testsuite/core.gdb.4154515.nelson.1656002338
 testsuite/core.gdb.4156668.nelson.1656002339
 testsuite/core.gdb.4158871.nelson.1656002341
 testsuite/core.gdb.468495.nelson.1656002444
 testsuite/core.vgdb.4192247.nelson.1656002366

where we can see that GDB crashed a number of times, but also
Valgrind's vgdb, and a couple testcase programs.  Neither of which is
good.

If your core_pattern is just "core" (but why??), then I guess that you
may end up with just a single core file in testsuite/.  Still, that is
one core file too many.

Above, we see a couple cores for "connect-with-no", which are the
result of gdb.server/connect-with-no-symbol-file.exp.  This is a case
mentioned above -- while the program crashed, that happens during
testcase teardown, and it goes unnoticed (without this commit) by
gdb.sum results.  Vis:

 $ make check TESTS="gdb.server/connect-with-no-symbol-file.exp"
 ...
 === gdb Summary ===

 # of unexpected core files      2
 # of expected passes            8

 ...
 $

The tests fully passed, but still the testcase program crashed
somehow:

 $ ls -1 testsuite/core.*
 testsuite/core.connect-with-no.941561.nelson.1656003317
 testsuite/core.connect-with-no.941682.nelson.1656003317

Against --target_board=native-extended-gdbserver it's even worse.  I
get:

 # of unexpected core files      26

and note that when GDBserver hits an assertion failure, it exits with
error, instead of crashing with SIGABRT.  I think that should be
changed, at least on development builds, but that would be for another
patch.  After such patch, I suspect the number of unexpected cores
will be higher, as there are likely teardown GDBserver assertions that
we're not noticing.

I decided to put this new info in the "gdb Summary" section, as that's
a place people already are used to looking at, either when looking at
the tail of gdb.sum, or when diffing gdb.sum files, and we've already
extended this section before, to include the count of DUPLICATE and
PATH problems, so there's precedent.

Implementation-wise, the new line is appended after DejaGnu is
finished, with a shell script that is invoked by the Makefile.  It is
done this way so that serial and parallel testing work the same way.
My initial cut at an implementation was in TCL, straight in
testsuite/lib/check-test-names.exp, where DUPLICATES and PATH are
handled, like so:

 @@ -148,6 +159,10 @@ namespace eval ::CheckTestNames {
     $counts(paths,$which)
 maybe_show_count "# of duplicate test names\t" \
     $counts(duplicates,$which)
 +
 +       set cores [glob -nocomplain -directory $::objdir core*]
 +       maybe_show_count "# of unexpected core files\t" \
 +           [llength $cores]
      }

But that would only work for serial testing, as in parallel testing,
the final gdb.sum is generated by aggregating the results of all the
individual gdb.sum files, and dg-extract-results.sh doesn't know about
our new summary line.  And I don't think that dg-extract-results.sh
should be taught about it, since the count of core files is not
something that we want to count many times, once per testcase, and
then add up the subcounts at the end.  Every time we count the core
files, we're already counting the final count.

I considered using the Tcl implementation in serial mode, and the
script approach for parallel testing, but that has the obvious
downside of implementing and maintaining the same thing twice.  In the
end, I settled on the script approach for serial mode too, which
requires making the "check-single" rule print the tail end of the
gdb.sum file, with a side effect being that if you look at the
terminal after a run (instead of at the gdb.sum file), you'll see the
"gdb Summary" section twice, once without the unexpected core lines
printed, and then another with.  IMO, this isn't an issue; when
testing in parallel mode, if you look at the terminal after "make -jN
check", you'll also see multiple "gdb Summary" sections printed.

Change-Id: I190b8d41856d49ad143854b6e3e6ccd7caa04491

Improve core file path detection & put cores in output dir

After a testrun, I noticed that I have some kernel-produced cores for
testcase programs, under build/gdb/testsuite/, which shouldn't be
there:

 $ ls -1 testsuite/core.*
 testsuite/core.annota1.1274351.nelson.1656004407
 testsuite/core.annota3.1288474.nelson.1656004414
 testsuite/core.exitsignal.1240674.nelson.1656004391

I have my core pattern setup like this:

 $ cat /proc/sys/kernel/core_pattern
 core.%e.%p.%h.%t

That's:

 %e: executable filename
 %p: pid
 %h: hostname
 %t: UNIX time of dump

so it's easy to tell which program produced the core from the core
file name.

From above, we can tell that the corresponding testcases are
gdb.base/annota1.exp, gdb.base/annota3.exp and
gdb.base/exitsignal.exp.

At least gdb.base/annota1.exp and gdb.base/annota3.exp have code in
them to delete the core file.  However, that isn't working for me,
because said code only looks for cores named exactly either "core" or
"core.PID", and my core_pattern doesn't match that.

Another issue I noticed, is that I have not been running
gdb.base/bigcore.exp, for a similar reason.  I get:

  Program terminated with signal SIGABRT, Aborted.
  The program no longer exists.
  (gdb) PASS: gdb.base/bigcore.exp: signal SIGABRT
  UNTESTED: gdb.base/bigcore.exp: can't generate a core file

But I actually have a core file under the testcase's output dir:

 $ find . -name "core.*"
 ./testsuite/outputs/gdb.base/bigcore/core.bigcore.2306705.nelson.1656005213
 $

This commit fixes these things, by adding a find_core_file routine
that searches core files in a way that works with my core pattern as
well.  This then also adds a convenience remove_core routine as a
wrapper around find_core_file that removes the found core file.

In addition, it changes some testcases that expect to have their
program dump core, to switch the inferior's cwd to the testcase's
output dir, so that the core is dumped there instead of in
build/gdb/testsuite/.  Some testcases were already doing that, but not
all.  The idea is that any core file dumped in build/gdb/testsuite/ is
an unexpected core file.  The next patch will add a count of such
unexpected core files to gdb.sum.

Another change is that the directory changing is now done with "set
cwd" instead of with "cd".  "set cwd" only affects the inferior cwd,
while "cd" affects GDB's cwd too.  By using "set cwd" instead of "cd",
if GDB dumps core in these testcases, the GDB core dump will still end
up in build/gdb/testsuite/, and can thus be detected as an unexpected
core.

Change-Id: I45068f21ffd4814350aaa8a3cc65cad5e3107607

gdb: make use of RAII in run_inferior_call

In passing I noticed that there are three local variables in
run_inferior_call that are used to save, and then restore some state,
I think these could all be replaced with a RAII style scoped_restore
instead.

Of the three locals that I've changed, the only one that I believe is
now restored in a different location is ui::async, before this commit
the async field was restored after a call to either delete_file_handle
or ui_register_input_event_handler, and after this commit, the field
is restored before these calls.  However, I don't believe that either
of these functions depend on the value of the async field, so I
believe the commit is fine.

Tested on x86-64/Linux passes with no regressions.

Delete delete_thread_silent

delete_thread_silent is no longer used anywhere.  Delete it.

Change-Id: Iafcec12339861d5ab2e29c14d7b1f884c9e11c0f

Automatic date update in version.in

Don't declare cli_set_logging

cli_set_logging is declared but not defined.  It's probably a leftover
from whenever interpreters were changed to use inheritance.  This
patch removes the declaration.  Tested by grep and rebuilding.

Use PyBool_FromLong

I noticed a few spots that were explicitly creating new references to
Py_True or Py_False.  It's simpler here to use PyBool_FromLong, so
this patch changes all the places I found.

PowerPC64: fix assertion in ppc_build_one_stub with -Os code

save_res stubs aren't written in ppc_build_one_stub, their offsets
(which are zero) should not be checked.

* elf64-ppc.c (ppc_build_one_stub): Don't check save_res offsets.

Re: PowerPC64: stub debug dump

Let's show the current stub as well as the previous one.  Of interest
is the current offset and a new field, id.  Check that the build
hash table traversal is in the same order as sizing traversal too.

* elf64-ppc.c (struct ppc_stub_hash_entry): Add id.
(struct ppc_link_hash_table): Add stub_id.
(stub_hash_newfunc): Init id and symtype.
(dump_stub): New function, extracted from..
(dump_previous_stub): ..here.  Deleted.
(ppc_build_one_stub): Sanity check stub id as well as offset.
Show current stub as well as previous.
(ppc_size_one_stub): Set stub id.
(ppc64_elf_size_stubs): Init stub_id before traversal.
(ppc64_elf_build_stubs): Likewise.

aarch64: Allow PC-relative relocations against protected STT_FUNC for -shared

    __attribute__((visibility("protected"))) void *foo() {
      return (void *)foo;
    }

gcc -fpic -shared -fuse-ld=bfd fails with the confusing diagnostic:

    relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `foo' which may bind externally can not be used when making a shared object; recompile with -fPIC

Call _bfd_elf_symbol_refs_local_p with local_protected==true to suppress
the error.  The new behavior matches gold and ld.lld.

Note: if some code tries to use direct access relocations to take the
address of foo (likely due to -fno-pic), the pointer equality will
break, but the error should be reported on the executable link, not on
the innocent shared object link.  glibc 2.36 will give a warning at
relocation resolving time.

aarch64: Define elf_backend_extern_protected_data to 0 [PR 18705]

Follow-up to commit 90b7a5df152a64d2bea20beb438e8b81049a5c30
("aarch64: Disallow copy relocations on protected data").

Commit 32f573bcb3aaa1c9defcad79dbb5851fcc02ae2d changed ld to produce
R_AARCH64_GLOB_DAT but that defeated the purpose of protected visibility
as an optimization.  Restore the previous behavior (which matches
ld.lld) by defining elf_backend_extern_protected_data to 0.

Automatic date update in version.in

Use std::string for interpreter_p

The global interpreter_p is a manually-managed 'char *'.  This patch
changes it to be a std::string instead, and removes some erroneous
comments.

Move mi_interpreter to mi-interp.h

I noticed that touching interps.h caused a lot of recompilation.  I
tracked this down to mi-common.h including this file.  This patch
moves the MI interpreter to mi-interp.h, which cuts down on
recompilation when modifying interps.h.

Use unique_xmalloc_ptr in interp

This changes interp::m_name to be a unique_xmalloc_ptr, removing some
manual memory management.  It also cleans up the initialization of the
'inited' member, and moves the 'private:' and 'public:' keywords to
their proper spots.

aarch64: Disallow copy relocations on protected data

If an executable has copy relocations for extern protected data, that
can only work if the shared object containing the definition is built
with assumptions (a) the compiler emits GOT-generating relocations (b)
the linker produces R_*_GLOB_DAT instead of R_*_RELATIVE.  Otherwise the
shared object uses its own definition directly and the executable
accesses a stale copy.  Note: the GOT relocations defeat the purpose of
protected visibility as an optimization, and it turns out this never
worked perfectly.

glibc 2.36 will warn on copy relocations on protected data.  Let's
produce a warning at link time, matching ld.lld which has been used on
many aarch64 OSes.

Note: x86 requires GNU_PROPERTY_NO_COPY_ON_PROTECTED to have the error.
This is to largely due to GCC 5's "x86-64: Optimize access to globals in
PIE with copy reloc" which started to use direct access relocations for
external data symbols in -fpie mode.

GCC's aarch64 port does not have the change.  Nowadays with most builds
switching to -fpie/-fpic, aarch64 mostly doesn't need to worry about
copy relocations.  So for aarch64 we simply don't check
GNU_PROPERTY_NO_COPY_ON_PROTECTED.

Binutils support for split-dwarf and dwarf-5

* dwarf.c (fetch_indexed_string): Added new parameter
str_offsets_base to calculate the string offset.
(read_and_display_attr_value): Read DW_AT_str_offsets_base
attribute.
(process_debug_info): While allocating memory and initializing
debug_information, do it for do_debug_info also, if its true.
(load_separate_debug_files): Load .debug_str_offsets if exists.
* dwarf.h (struct debug_info): Add str_offsets_base field.