add a trie to map quickly from address range to compilation unit

When using perf to profile large binaries, _bfd_dwarf2_find_nearest_line()
becomes a hotspot, as perf wants to get line number information
(for inline-detection purposes) for each and every sample. In Chromium
in particular (the content_shell binary), this entails going through
475k address ranges, which takes a long time when done repeatedly.

Add a radix-256 trie over the address space to quickly map address to
compilation unit spaces; for content_shell, which is 1.6 GB when some
(but not full) debug information turned is on, we go from 6 ms to
0.006 ms (6 µs) for each lookup from address to compilation unit, a 1000x
speedup.

There is a modest RAM increase of 180 MB in this binary (the existing
linked list over ranges uses about 10 MB, and the entire perf job uses
between 2–3 GB for a medium-size profile); for smaller binaries with few
ranges, there should be hardly any extra RAM usage at all.

Tidy warn-execstack handling

Make ld and bfd values consistent by swapping values 0 and 2 in
link_info.warn_execstack.  This has the benefit of making the value an
"extended" boolean, with 0 meaning no warning, 1 meaning warn, other
values a conditional warning.

Yes, this patch introduces fails on arm/aarch64.  Not a problem with
this patch but an arm/aarch64 before_parse problem.

bfd/
* elflink.c (bfd_elf_size_dynamic_sections): Adjust
warn_execstack test.
include/
* bfdlink.h (warn_execstack): Swap 0 and 2 meaning.
ld/
* configure.ac (DEFAULT_LD_WARN_EXECSTACK): Use values of 0,
1, 2 consistent with link_info.warn_execstack.
* ld.texi: Typo fixes.
* lexsup.c (parse_args): Adjust setting of link_info.warn_execstack.
(elf_static_list_options): Adjust help message conditions.
* configure: Regenerate.

Automatic date update in version.in

arm: Fix system register fpcxt_ns and fpcxt_s naming convention.

The current assembler accepts system registers FPCXTNS and FPCXTS for Armv8.1-M
Mainline Instructions VSTR, VLDR, VMRS and VMSR.
Assembler should be also allowing FPCXT_NS, fpcxt_ns, fpcxtns, FPCXT_S, fpcxt_s
and fpcxts. This patch fixes the issue.

gdb/doc: use @value{GDBP} in 'info pretty-printer' example

Update the 'info pretty-printer' example in the manual to make use of
@value{GDBP} instead of hard-coding '(gdb)'.

gdb/doc: make use of group/end group in 'info pretty-printers' example

The 'info pretty-printers' example is pretty long and consists of many
commands and their output.

Currently, when the pdf manual is generated this example spans a
page-break, with the page-break falling part way through some example
output from GDB.

This commit breaks up the example using @group .... @end group, within
each group is a single GDB command and all its output.

Now, when the pdf manual is created, the page-break is placed after
the output of one GDB command, and before the subsequent command, this
looks much nicer.

gdb/doc: fix inconsistent info pretty-printer example

The example for 'info pretty-printer' in the manual passes an
object-regexp in some cases, but presents output as though no
object-regexp was passed.

This commit fixes the two mistakes, in one case, fixing the output to
filter based on object-regexp, and in the other, to remove the
object-regexp from the command and leave all the output.

Fix potentially uninitialised variables in the Windows tools

gdb: testsuite: Support displaced stepping on LoongArch

When execute the following command on LoongArch:

  make check-gdb TESTS="gdb.base/async-shell.exp"

we can see the following message in gdb/testsuite/gdb.sum:

  UNSUPPORTED: gdb.base/async-shell.exp: displaced stepping

modify support_displaced_stepping to support displaced stepping
on LoongArch.

With this patch:

  PASS: gdb.base/async-shell.exp: run &
  PASS: gdb.base/async-shell.exp: shell echo foo
  PASS: gdb.base/async-shell.exp: interrupt
  PASS: gdb.base/async-shell.exp: process stopped

I did the following tests that use support_displaced_stepping
with this patch on LoongArch, there is no failed testcases.

loongson@linux:~/gdb.git$ grep -r support_displaced_stepping gdb/testsuite/gdb.*
gdb/testsuite/gdb.arch/disp-step-insn-reloc.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.base/step-over-no-symbols.exp:    if { $displaced != "off" && ![support_displaced_stepping] } {
gdb/testsuite/gdb.base/moribund-step.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.base/async-shell.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.base/inferior-died.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.base/step-over-syscall.exp:        if {$displaced == "on" && ![support_displaced_stepping]} {
gdb/testsuite/gdb.mi/mi-watch-nonstop.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.mi/mi-ns-stale-regcache.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.mi/mi-nonstop.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.mi/mi-nsmoribund.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.mi/mi-nsintrall.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.mi/mi-nsthrexec.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.mi/mi-nonstop-exit.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.multi/watchpoint-multi.exp:if [support_displaced_stepping] {
gdb/testsuite/gdb.python/py-evthreads.exp:if { ![support_displaced_stepping] } {
gdb/testsuite/gdb.threads/step-over-lands-on-breakpoint.exp:    if { $displaced != "off" && ![support_displaced_stepping] } {
gdb/testsuite/gdb.threads/interrupt-while-step-over.exp:    if { ${displaced-stepping} != "off" && ![support_displaced_stepping] } {
gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.exp:    if { $displaced != "off" && ![support_displaced_stepping] } {

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

gdbsupport: fix path_join crash with -std=c++17 and -D_GLIBCXX_DEBUG

When building GDB with -std=c++17 and -D_GLIBCXX_DEBUG=1, I get:

  $ ./gdb -nx --data-directory=data-directory -q -ex "maint selftest path_join"
  /usr/include/c++/11.2.0/string_view:233: constexpr const value_type& std::basic_string_view<_CharT, _Traits>::operator[](std::basic_string_view<_CharT, _Traits>::size_type) const [with _CharT = char; _Traits = std::char_traits<char>; std::basic_string_view<_CharT, _Traits>::const_reference = const char&; std::basic_string_view<_CharT, _Traits>::size_type = long unsigned int]: Assertion  '__pos < this->_M_len' failed.

The problem is that we're passing an empty string_view to
IS_ABSOLUTE_PATH.  IS_ABSOLUTE_PATH accesses [0] on that string_view,
which is out-of-bounds.

The reason this is not seen with -std less than c++17 is that our local
copy of string_view (used with C++ < 17) does not have the assert in
operator[], as that wouldn't work in a constexpr method:

  https://gitlab.com/gnutools/binutils-gdb/-/blob/5890af36e5112bcbb8d7555e63570f68466e6944/gdbsupport/gdb_string_view.h#L180

IS_ABSOLUTE_PATH is normally used with null-terminated string.  It's
fine to pass an empty null-terminated string to IS_ABSOLUTE_PATH,
because index 0 in such a string is valid.  But not with an empty
string_view.

Fix that by avoiding the "call" to IS_ABSOLUTE_PATH if the string_view
is empty.

Change-Id: Idf4df961b63f513b3389235e93814c02b89ea32e

Arm64: force emission of ILP32-dependent relocs

Like the placeholder types added in 04dfe7aa5217 ("Arm64: follow-on to
PR gas/27217 fix"), these are also placeholders which are subsequently
resolved (albeit later, hence this being a separate issue). As for the
resolved types 1 is returned, these pseudo-relocs should also have 1
returned to force retaining of the [eventual] relocations. This is also
spelled out individually for each of them in md_apply_fix().

COFF: use hash for string table also when copying / stripping

Otherwise the string table may grow and hence e.g. change a final binary
(observed with PE/COFF ones) even if really there's no change. Doing so
in fact reduces the overall amount of code, and in particular the number
of places which need to remain in sync.

Afaics there's no real equivalent to the "traditional_format" field used
when linking, so hashing is always enabled when copying / stripping.

COFF/PE: keep linker version during objcopy / strip

Neither of the tools is really a linker, so whatever was originally
recorded should be retained rather than being overwritten by these
tools' versions.

COFF/PE: don't leave zero timestamp after objcopy / strip

Fill the timestamp field suitably for _bfd_XXi_only_swap_filehdr_out().
Instead of re-arranging the present if(), fold this logic with that of
copying the optional header.

COFF: make objcopy / strip honor --keep-file-symbols

So far this option had no effect when used together with e.g.
--strip-debug. Set BSF_FILE on these symbols to change that.

While altering this also join two adjacent blocks of case labeled
statements with identical code.

don't over-align file positions of PE executable sections

When a sufficiently small alignment was specified via --file-alignment,
individual section alignment shouldn't affect placement within the file.
This involves first of all clearing D_PAGED for images when section and
file alignment together don't permit paging of the image. The involved
comparison against COFF_PAGE_SIZE in turn helped point out (through a
compiler warning) that 'page_size' should be of unsigned type (as in
particular FileAlignment is). This yet in turn pointed out a dubious
error condition (which is being deleted).

For the D_PAGED case I think the enforced file alignment may still be
too high, but I'm wary of changing that logic without knowing of
possible corner cases.

Furthermore file positions in PE should be independent of the alignment
recorded in section headers anyway. Otherwise there are e.g. anomalies
following commit 6f8f6017a0c4 ("PR27567, Linking PE files adds alignment
section flags to executables") in that linking would use information a
subsequent processing step (e.g. stripping) wouldn't have available
anymore, and hence a binary could change in that 2nd step for no actual
reason. (Similarly stripping a binary linked with a linker pre-dating
that commit would change the binary again when stripping it a 2nd time.)

 _bfd_real_fopen should not use ccs parameter on Windows

PR 25713
* bfdio.c (_bfd_real_fopen): Delete ccs string.

RISC-V: Fix canonical extension order (K and J)

This commit fixes canonical extension order to follow the RISC-V ISA
Manual draft-20210402-1271737 or later.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_recognized_prefixed_ext): Fix "K" extension
prefix to be placed before "J".

Automatic date update in version.in

Use aarch64_features to describe register features in target descriptions.

Replace the sve bool member of aarch64_features with a vq member that
holds the vector quotient.  It is zero if SVE is not present.

Add std::hash<> specialization and operator== so that aarch64_features
can be used as a key with std::unordered_map<>.

Change the various functions that create or lookup aarch64 target
descriptions to accept a const aarch64_features object rather than a
growing number of arguments.

Replace the multi-dimension tdesc_aarch64_list arrays used to cache
target descriptions with unordered_maps indexed by aarch64_feature.

Arm64: follow-on to PR gas/27217 fix

PR gas/27217

Prior to trying to address PR gas/28888 I noticed anomalies in how
certain insns would / wouldn't be affected in similar ways.

Commit eac4eb8ecb26 ("Fix a problem assembling AArch64 sources when a
relocation is generated against a symbol that has a defined value") had
two copy-and-paste mistakes, passing the wrong type to
aarch64_force_reloc().

It further failed to add placeholder relocation types to that function's
block of case labels leading to a return of 1. While not of interest for
aarch64_force_relocation() (these placeholders are resolved right in
parse_operands()), calls to aarch64_force_reloc() happen before that
resolution would take place.

Fix compile time warning building gold with Clang-14.

* int_encoding.cc (get_length_as_unsigned_LEB_128): Remove
current_length variable.

oops - forgot changelog entry for the previous delta.

arm: Add unwind support for mixed register lists

* config/tc-arm.c (parse_reg_list): Add handling of mixed register
types.
(reg_names): Enumerate pseudoregister according to mapped physical
register number.
(s_arm_unwind_save_pseudo): Modify function signature.
(s_arm_unwind_save_core): Likewise.
(s_arm_unwind_save_mixed): New function.
(s_arm_unwind_save): Generate register list mask to pass to nested
functions.
* testsuite/gas/arm/unwind-pacbti-m.s: Expand test for mixed
  register type lists.
  * testsuite/gas/arm/unwind-pacbti-m.d: Likewise.
* testsuite/gas/arm/unwind-pacbti-m-readelf.d: Likewise.

PowerPC: bp-permanent.exp, kill-after-signal fix

Fix changes that didn't make it into commit:
dd9cd55e990bcc9f8448cac38d242d53974b3604.

Fix missing -wrap on gdb_test_multiple in gdb.base/kill-after-signal.exp
that is causing regression test on x86_64-linux with taskset -c 0.

[AArch64] Return the regnum for PC (32) on aarch64

This will allow the unwind info to explicitly specify a different value
for the return address from the link register.
Such usage, although uncommon, is valid and useful for signal frames.
It is also supported by aadwarf64 from ARM (Note 9 in [1]).

Ref https://sourceware.org/pipermail/gdb/2022-May/050091.html

[1] https://github.com/ARM-software/abi-aa/blob/2022Q1/aadwarf64/aadwarf64.rst#dwarf-register-names

Signed-off-by: Luis Machado <luis.machado@arm.com>

x86: shrink op_riprel

It is only ever initialized from a boolean, so it as well as related
variables' types can simply be bool and there's no masking to 32 bits
needed in set_op().

Add a --no-weak option to nm.

PR 29135
* nm.c (non_weak): New variable.
(filter_symbols): When non-weak is true, ignore weak symbols.
(long_options): Add --no-weak.
(usage): Mention --no-weak.
(main): Handle -W/--no-weak.
* doc/binutils.texi: Document new feature.
* NEWS: Mention the new feature.
* testsuite/binutils-all/nm.exp: Add test of new feature.
* testsuite/binutils-all/no-weak.s: New test source file.

Support -prompt and -lbl in gdb_test

This teaches gdb_test to forward the -prompt and -lbl options to
gdb_test_multiple.

The option parsing is done with parse_args.

As a cleanup, instead of using llength and lindex to get at the
positional arguments, use lassign, and check whether the corresponding
variable is empty.

Convert gdb.base/ui-redirect.exp and gdb.xml/tdesc-reload.exp to use
gdb_test -prompt/-lbl instead of gdb_test_multiple as examples.

Change-Id: I243e1296d32c05a421ccef30b63d43a89eaeb4a0

Remove unused DWARF PAUTH registers

The AARCH64_DWARF_PAUTH_DMASK and AARCH64_DWARF_PAUTH_CMASK DWARF registers
never made their way into the aadwarf64. The following patch removes these
constants and their use.

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

Rename PAUTH_RA_STATE to RA_SIGN_STATE

The aadwarf64 [1] names this register RA_SIGN_STATE, so update the code to use
the same name.

[1] https://github.com/ARM-software/abi-aa/blob/main/aadwarf64/aadwarf64.rst

[gdb/testsuite] Simplify unknown lang testing in gdb.base/parse_number.exp

Move testing of language unknown out of the $supported_archs loop in
gdb.base/parse_number.exp.  This reduces total amount of tests from 18466 to
17744.

Tested on x86_64-linux.

[gdb/testsuite] Use hex_for_lang in gdb.base/parse_number.exp

In gdb.base/parse_number.exp, add a new proc hex_for_lang that formats a hex
number appropriately for a given language.

Tested on x86_64-linux.

[gdb/tdep] Add gdb/syscalls/update-linux-from-src.sh

Add a new script gdb/syscalls/update-linux-from-src.sh, that can be used to
generate *-linux.xml.in files from linux kernel sources, like so:
...
$ ./update-linux-from-src.sh ~/upstream/linux-stable.git
Skipping aarch64-linux.xml.in, no syscall.tbl
Generating amd64-linux.xml.in
Skipping arm-linux.xml.in, use arm-linux.py instead
Skipping bfin-linux.xml.in, no longer supported
Generating i386-linux.xml.in
Generating mips-n32-linux.xml.in
Generating mips-n64-linux.xml.in
Generating mips-o32-linux.xml.in
Generating ppc64-linux.xml.in
Generating ppc-linux.xml.in
Generating s390-linux.xml.in
Generating s390x-linux.xml.in
Generating sparc64-linux.xml.in
Generating sparc-linux.xml.in
...

Update *-linux.xml.in and *-linux.xml using linux kernel tag v5.18-rc6.

AArch64: Enable FP16 by default for Armv9-A.

In Armv9-A SVE is mandatory, and for SVE FP16 is mandatory.  This fixes a disconnect
between GCC and binutils where GCC has FP16 on by default and gas doesn't.

include/ChangeLog:

2022-05-16  Tamar Christina  <tamar.christina@arm.com>

* opcode/aarch64.h (AARCH64_ARCH_V9_FEATURES): Add AARCH64_FEATURE_F16.

gas: avoid octal numbers being accepted when processing .linefile

Compilers would put decimal numbers there, so I think we should treat
finding octal numbers the same as finding bignums - ignore them as
actually being comments of some very specific form.

gas: avoid bignum related errors when processing .linefile

Any construct which to the scrubber looks like a C preprocessor
line/file "directive" is converted to .linefile, but the amount of
checking the scrubber does is minimal (albeit it does let through only
decimal digits for the line part of the contruct). Since the scrubber
conversion is further tied to # being a line comment character, anything
which upon closer inspection turns out not to be a line/file "directive"
is supposed to be treated as a comment, i.e. ignored. Therefore we
cannot use get_absolute_expression(), as this may raise errors. Open-
code the function instead, treating everything not resulting in
O_constant as a comment as well.

Furthermore also bounds-check the parsed value. This bounds check tries
to avoid implementation defined behavior (which may be the raising of an
implementation defined signal), but for now makes the assumption that
int has less than 64 bits. The way bfd_signed_vma (which is what offsetT
aliases) is defined in bfd.h for the BFD64 case I cannot really see a
clean way of avoiding this assumption. Omitting the #ifdef, otoh, would
risk "condition is always false" warnings by compilers.

Convert get_linefile_number() to return bool at this occasion as well.

gas: fold do_repeat{,_with_expander}()

do_repeat_with_expander() already deals with the "no expander" case
quite fine, so there's really little point having two functions. What it
lacks compared with do_repeat() is a call to sb_build(), which can
simply be moved (and the then redundant sb_new() be avoided). Along with
this moving also flip if the main if()'s condition such that the "no
expander" case is handled first.

gas: don't ignore .linefile inside false conditionals

When assembling code previously pre-processed by a C compiler, long
enough comments may have been collapsed into "# <line> <file>"
constructs. If we skip these, line numbers (and possibly even file
names) will be off / wrong in both diagnostics and debug info.

gas: simplify ignore_input()

First of all convert to switch(), in preparation of adding another
directive here which may not be ignored. While doing so drop dead code:
A string the first two characters of which do not match "if" also wont
match "ifdef" or "ifndef".

gas: tweak .irp and alike file/line handling for M68K/MRI

In commit 2ee1792bec22 ("gas: further adjust file/line handling for .irp
and alike") I neglected the need to omit the leading . in M68K/MRI mode.

gold: don't invoke IA32 syscall in x86_64 assembly testcase

pr17704a_test.s is a x86_64 assembly file, but it invokes IA32 exit
syscall with "int 0x80".  This causes a segfault on kernels with
CONFIG_IA32_EMULATION disabled.

gold/

* testsuite/pr17704a_test.s (_start): Invoke x86_64 exit syscall
instead of its IA32 counterpart.

Automatic date update in version.in

Fix typo in info page

Fix gdb.python/py-connection.exp with remote targets

After the patch to make gdb_test's question non-optional when
specified, gdb.python/py-connection.exp started failing like so:

  $ make check TESTS="gdb.python/py-connection.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
  (gdb) PASS: gdb.python/py-connection.exp: info connections while the connection is still around
  disconnect^M
  Ending remote debugging.^M
  (gdb) FAIL: gdb.python/py-connection.exp: kill the inferior

The problem is that "disconnect" when debugging with the native target
asks the user whether to kill the program, while with remote targets,
it doesn't.

Fix it by explicitly killing before disconnecting.

Tested with --target_board unix, native-gdbserver, and native-extended-gdbserver.

Change-Id: Icd85015c76deb84b71894715d43853c1087eba0b

gdb, btrace: Throw an error for empty recordings when replaying starts.

This makes record_btrace_start_replaying() more consistent, as it already
errors out e.g. on a recording with only gaps.

Make gdb_test's question non-optional if specified

gdb_test supports handling scenarios where GDB asks a question before
finishing handling some command.  The full prototype of gdb_test is:

  # gdb_test COMMAND PATTERN MESSAGE QUESTION RESPONSE

However, QUESTION is a question that GDB _may_ ask, not one that GDB
_must_ ask:

 # QUESTION is a question GDB may ask in response to COMMAND, like
 #   "are you sure?"
 # RESPONSE is the response to send if QUESTION appears.

If GDB doesn't raise the question, the test still passes.

I think that this is a misfeature.  If GDB regresses and stops asking
a question, the testsuite won't notice.  So I think that if a QUESTION
is specified, gdb_test should ensure it comes out of GDB.

Running the testsuite exposed a number of tests that pass
QUESTION/RESPONSE to GDB, but no question comes out.  The previous
commits fixed them all, so this commit changes gdb_test's behavior.

A related issue is that gdb_test doesn't enforce that if you specify
QUESTION, that you also specify RESPONSE.  I.e., you should pass 1, 2,
3, or 5 arguments to gdb_test, but never 4, or more than 5.  Making
gdb_test detect bogus arguments actually regressed some testcases,
also all fixed in previous commits.

Change-Id: I47c39c9034e6a6841129312037a5ca4c5811f0db

gdb.base/skip.exp: Don't abuse gdb_test's question support

gdb.base/skip.exp abuses gdb_test's support for answering a GDB
question to do this:

    # With gcc 9.2.0 we jump once back to main before entering foo here.
    # If that happens try to step a second time.
    gdb_test "step" "foo \\(\\) at.*" "step 3" \
"main \\(\\) at .*\r\n$gdb_prompt " "step"

After a patch later in this series, gdb_test will FAIL if GDB does NOT
issue the question, so this test would start failing on older GCCs.

Switch to using gdb_test_multiple instead.  There are three spots in
the file that have the same pattern, and they're actually in a
sequence of commands that is repeated those 3 times.  Factor all that
out to a procedure.

I don't have gcc 9.2 handy, but I do have gcc 6.5, and that one is
affected as well, so update the comment.

Change-Id: If0a7e3cdf5191b4eec95ce0c8845c3a4d801c39e

Avoid having to unload file in gdb.server/connect-with-no-symbol-file.exp

gdb.server/connect-with-no-symbol-file.exp's connect_no_symbol_file
does:

gdb_test "file" ".*" "discard symbol table" \
    {Discard symbol table from `.*'\? \(y or n\) } "y"

A following patch will make gdb_test expect the question out of GDB if
one is passed down as argument to gdb_test.  With that, this test
starts failing.  This is because connect_no_symbol_file is called in a
loop, and the first time around, there's a loaded file, so "file" asks
the "Discard symbol table ... ?" question, while in the following
iterations there's no file, so there's no question.

Fix this by not loading a file into GDB in the first place.

Change-Id: I810c036b57842c4c5b47faf340466b0d446d1abc

Fix bogus gdb_test invocations

A following patch will make gdb_test error out if bogus arguments are
passed, which exposed bugs in a few testcases:

 - gdb.python/py-parameter.exp, passing a spurious "1" as extra
   parameter, resulting in:

   ERROR: Unexpected arguments: {set test-file-param bar.txt} {The name of the file has been changed to bar.txt} {set new file parameter} 1

 - gdb.python/py-xmethods.exp, a missing test message, resulting in
   the next gdb_test being interpreted as message, question and
   response!  With the enforcing patch, this was caught with:

   ERROR: Unexpected arguments: {p g.mul<char>('a')} {From Python G<>::mul.*} gdb_test {p g_ptr->mul<char>('a')} {From Python G<>::mul.*} {after: g_ptr->mul<char>('a')}

 - gdb.base/pointers.exp, missing a quote.

Change-Id: I66f2db4412025a64121db7347dfb0b48240d46d4

gdb.base/scope.exp: Remove bogus gdb_test questions

This test is abusing the QUESTION/RESPONSE feature to send an
alternative command to GDB if the first command fails.  Like so:

   gdb_test "print 'scope0.c'::filelocal" \
    "\\\$$decimal = 1" "print 'scope0.c'::filelocal at main" \
    "No symbol \"scope0.c\" in current context.*" \
    "print '$srcdir/$subdir/scope0.c'::filelocal"

So if 'scope0.c' doesn't work, we try again with
'$srcdir/$subdir/scope0.c'.  I strongly suspect this is really an
obsolete test.  I think that if '$srcdir/$subdir/scope0.c' works, then
'scope0.c' should have worked too, thus I'd think that if we pass due
to the question path, then it's a bug.  So just remove the question
part passed to gdb_test.

Change-Id: I2acc99285f1d519284051b49693b5441fbdfe3cd

Remove gdb_test questions that GDB doesn't ask

Change-Id: Ib2616dc883e9dc9ee100f6c86d83a921a0113c16

RISC-V: Added half-precision floating-point v1.0 instructions.

bfd/
* elfxx-riscv.c (riscv_implicit_subsets): Added implicit f
and zicsr for zfh.
(riscv_supported_std_z_ext): Added default v1.0 version for zfh.
(riscv_multi_subset_supports): Handle INSN_CLASS_ZFH,
INSN_CLASS_D_AND_ZFH and INSN_CLASS_Q_AND_ZFH.
gas/
* config/tc-riscv.c (FLT_CHARS): Added "hH".
(macro): Expand Pseudo M_FLH and M_FSH.
(riscv_pseudo_table): Added .float16 directive.
* testsuite/gas/riscv/float16-be.d: New testcase for .float16.
* testsuite/gas/riscv/float16-le.d: Likewise.
* testsuite/gas/riscv/float16.s: Likewise.
* testsuite/gas/riscv/fp-zfh-insns.d: New testcase for zfh.
* testsuite/gas/riscv/fp-zfh-insns.s: Likewise.
include/
* opcode/riscv-opc.h: Added MASK and MATCH encodings for zfh.
* opcode/riscv.h: Added INSN_CLASS and pseudo macros for zfh.
opcodes/
* riscv-opc.c (riscv_opcodes): Added zfh instructions.

Automatic date update in version.in

IBM zSystems: Fix left-shifting negative PCRel32 values (PR gas/29152)

s390_insert_operand ()'s val, min and max are encoded PCRel32 values
and need to be left-shifted by 1 before being shown to the user.
Left-shifting negative values is undefined behavior in C, but the
current code does not try to prevent it, causing UBSan to complain.

Fix by casting the values to their unsigned equivalents before
shifting.

Reindent gdbsupport/event-loop.cc:handle_file_event

The handle_file_event function has a few unnecessary {} lexical
blocks, presumably because they were originally if blocks, and the
conditions were removed, or something along those lines.

Remove the unnecessary blocks, and reindent.

Change-Id: Iaecbe5c9f4940a80b81dbbc42e51ce506f6aafb2

gdbsupport/event-loop.cc: simplify !HAVE_POLL paths

gdbsupport/event-loop.cc throughout handles the case of use_poll being
true on a system where HAVE_POLL is not defined, by calling
internal_error if that situation ever happens.

Simplify this by moving the "use_poll" global itself under HAVE_POLL,
so that it's way more unlikely to ever end up in such a situation.
Then, move the code that checks the value of use_poll under HAVE_POLL
too, and remove the internal_error calls.  Like, from:

    if (use_poll)
      {
  #ifdef HAVE_POLL
        // poll code
  #else
      internal_error (....);
  #endif /* HAVE_POLL */
      }
    else
      {
// select code
      }

to

  #ifdef HAVE_POLL
    if (use_poll)
      {
        // poll code
      }
    else
  #endif /* HAVE_POLL */
      {
// select code
      }

While at it, make use_poll be a bool.  The current code is using
unsigned char most probably to save space, but I don't think it really
matters here.

Co-Authored-By: Youling Tang <tangyouling@loongson.cn>
Change-Id: I0dd74fdd4d393ccd057906df4cd75e8e83c1cdb4

gdb: Fix typo in last change in gdb.texinfo

gdb: Document the 'metadata' styling in GDB displays.

The 'metadata' styling was never documented in the GDB manual.
This fills that gap.

Fix Ada exception regression on Windows

The breakpoint c++-ification series introduced another bug in Ada --
it caused "catch exception" and related commands to fail on Windows.
The problem is that the re_set method calls the wrong superclass
method, so the breakpoint doesn't get correctly re-set when the
runtime offsets change.  This patch fixes the problem.

gdb/testsuite: fix "continue outside of loop" TCL errors

Many test cases had a few lines in the beginning that look like:

if { condition } {
  continue
}

Where conditions varied, but were mostly in the form of ![runto_main] or
[skip_*_tests], making it quite clear that this code block was supposed
to finish the test if it entered the code block. This generates TCL
errors, as most of these tests are not inside loops.  All cases on which
this was an obvious mistake are changed in this patch.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Remove unused field cooked_index::m_start

cooked_index::m_start is unused and can be removed.  I think this was
a leftover from a previous approach in the index finalization code,
and then when rewriting it I forgot to remove it.

Tested by rebuilding.

Implement pid_to_exec_file for Windows in gdbserver

I noticed that gdbserver did not implement pid_to_exec_file for
Windows, while gdb did implement it.  This patch moves the code to
nat/windows-nat.c, so that it can be shared.  This makes the gdbserver
implementation trivial.

Remove windows_process_info::id

I noticed that windows_process_info::id is only used by gdbserver, and
not really necessary.  This patch removes it.

Constify target_pid_to_exec_file

This changes target_pid_to_exec_file and target_ops::pid_to_exec_file
to return a "const char *".  I couldn't build many of these targets,
but did examine the code by hand -- also, as this only affects the
return type, it's normally pretty safe.  This brings gdb and gdbserver
a bit closer, and allows for the removal of a const_cast as well.

Put corefile-run.core into test subdirectory

I noticed that corefile-run.core ends up in the 'runtest' directory.
It's better, when at all possible, for test files to end up in the
test's designated subdirectory.  This patch makes this change.

Do not double-read minimal symbols for PE COFF

This changes coffread.c to avoid re-reading minimal symbols when
possible.  This only works when there are no COFF symbols to be read,
but at least for my mingw builds of gdb, this seems to be the case.

Tested using the AdaCore internal test suite on Windows.  I also did
some local builds to ensure that no warnings crept in.

Fix "gdb --write" with core files

If you load a core file into GDB with the --write option, or "set
write on" (equivalent), and then poke memory expecting it to patch the
core binary, you'll notice something odd -- the write seems to
succeed, but in reality, it doesn't.  The value you wrote doesn't
persist.  Like so:

 $ gdb -q --write -c testsuite/outputs/gdb.base/patch/gcore.test
 [New LWP 615986]
 Core was generated by `/home/pedro/gdb/build/gdb/testsuite/outputs/gdb.base/patch/patch'.
 Program terminated with signal SIGTRAP, Trace/breakpoint trap.
 #0  0x0000555555555131 in ?? ()
 (gdb) p *(unsigned char *)0x0000555555555131 = 1
 $1 = 1 '\001'
 (gdb) p *(unsigned char *)0x0000555555555131
 $2 = 185 '\271'
 (gdb)

Diffing hexdumps of before/after patching, reveals that a "0x1" was
actually written somewhere in the file.  The problem is that the "0x1"
was written at the wrong offset in the file...

That happens because _bfd_elf_set_section_contents does this to seek
to the section's offset:

  pos = hdr->sh_offset + offset;
  if (bfd_seek (abfd, pos, SEEK_SET) != 0
      || bfd_bwrite (location, count, abfd) != count)
    return false;

... and 'hdr->sh_offset' is zero, so we seek to just OFFSET, which is
incorrect.  The reason 'hdr->sh_offset' is zero is that
kernel-generated core files normally don't even have a section header
table (gdb-generated ones do, but that's more an accident than a
feature), and indeed elf_core_file_p doesn't even try to read sections
at all:

  /*  Core files are simply standard ELF formatted files that partition
      the file using the execution view of the file (program header table)
      rather than the linking view.  In fact, there is no section header
      table in a core file.

      The process status information (including the contents of the general
      register set) and the floating point register set are stored in a
      segment of type PT_NOTE.  We handcraft a couple of extra bfd sections
      that allow standard bfd access to the general registers (.reg) and the
      floating point registers (.reg2).  */

  bfd_cleanup
  elf_core_file_p (bfd *abfd)

Changing _bfd_elf_set_section_contents from:

  pos = hdr->sh_offset + offset;

to:

  pos = section->filepos + offset;

fixes it.  If we do that however, the tail end of
_bfd_elf_set_section_contents ends up as a copy of
_bfd_generic_set_section_contents, so just call the latter, thus
eliminating some duplicate code.

New GDB testcase included, which exercises both patching an executable
and patching a core file.  Patching an executable already works
without this fix, because in that case BFD reads in the sections
table.  Still, we had no testcase for that yet.  In fact, we have no
"set write on" testcases at all, this is the first one.

Tested on x86-64 GNU/Linux, gdb, ld, binutils, and gas.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18227
Change-Id: I0f49f58b48aabab2e269f2959b8fd8a7fe36fdce

Import libiberty from gcc

sim: remove use of PTR

PTR will soon disappear from ansidecl.h.  Remove uses in sim.  Where
a PTR cast is used in assignment or function args to a void* I've
simply removed the unnecessary (in C) cast rather than replacing with
(void *).

Automatic date update in version.in

gdb: remove use of PTR

PTR will disappear from ansidecl.h and libiberty on the next import
from gcc.  Remove current uses in gdb.

[gdb/testsuite] Fix gdb.cp/break-f-std-string.cc with older gcc

When running test-case gdb.cp/break-f-std-string.exp on openSUSE Leap 15.3
with system gcc 7.5.0, I run into:
...
(gdb) whatis /r std::string^M
No symbol "string" in namespace "std".^M
(gdb) FAIL: gdb.cp/break-f-std-string.exp: _GLIBCXX_USE_CXX11_ABI=1: \
  whatis /r std::string
...
The same for gcc 8.2.1, but it passes with gcc 9.3.1.

At source level (as we can observe in the .ii file with -save-temps) we have
indeed:
...
namespace std {
  namespace __cxx11 {
    typedef basic_string<char> string;
  }
}
...
while with gcc 9.3.1, we have instead:
...
namespace std {
  namespace __cxx11 {
    ...
  }
  typedef basic_string<char> string;
}
...
due to gcc commit 33b43b0d8cd ("Define std::string and related typedefs
outside __cxx11 namespace").

Fix this by adding the missing typedef for gcc version 5 (the first version to
have the dual abi) to 8 (the last version missing aforementioned gcc commit).

Tested on x86_64-linux, with:
- system gcc 7.5.0
- gcc 4.8.5, 8.2.1, 9.3.1, 10.3.0, 11.2.1
- clang 8.0.1, 12.0.1

Fix an illegal memory access when creating DLLs.

PR 29006
* pe-dll.c (dll_name): Delete, replacing with..
(dll_filename): ..this, moved earlier in file.
(generate_edata): Delete parameters.  Don't set up dll_name here..
(pe_process_import_defs): ..instead set up dll_filename and
dll_symname here before returning.
(dll_symname_len): Delete write-only variable.
(pe_dll_generate_implib): Don't set up dll_symname here.

gdb: Workaround stringop-overread warning in debuginfod-support.c on powerpc64

Just like on s390x with g++ 11.2.1, ppc64le with g++ 11.3.1 produces a
spurious warning for stringop-overread in debuginfod_is_enabled
for url_view. Also suppress it on powerpc64.

 gdb/ChangeLog:

    * debuginfod-support.c (debuginfod_is_enabled): Use
      DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD on powerpc64.

Make gdb.ada/float-bits.exp more generic

There are assumptions in the test about the long double format
being used. While the results are OK for i387 128-bit long doubles, it
is not correct for IEEE quad 128-bit long doubles.

Also, depending on the target (64-bit/32-bit), long doubles may not
be available at all. And it may be the case that the compiler for a 64-bit
target doesn't support 128-bit long doubles, but GDB might still support it
internally.

Lastly, not every long double format has invalid values. Some formats
consider all values as valid floating point numbers.

These divergences cause the following FAIL's on aarch64/arm:

FAIL: gdb.ada/float-bits.exp: print val_long_double
FAIL: gdb.ada/float-bits.exp: print val_long_double after assignment

With the above in mind, extend the test a little so it behaves well on
different architectures and so it works with different long double
formats.

Main changes:

- Use long double values appropriate for the long double format.
- Test long double assignment to compiler-generated long
  double variables.
- Test long double assignment to GDB internal variables.

Tested on x86_64 (16 PASS), i686 (16 PASS), aarch64 (12 PASS) and arm (9 PASS).

[gdb/tdep] Improve gdb/syscalls/update-linux.sh

Fix two things in update-linux.sh:
- remove use of unnecessary tmp file
- inline gen-header.py into update-linux.sh

Tested on x86_64-linux.

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

On aarch64-linux, with test-case gdb.dwarf2/dw2-out-of-range-end-of-seq.exp I
run into:
...
(gdb) run ^M
Starting program: dw2-out-of-range-end-of-seq ^M
^M
Program received signal SIGILL, Illegal instruction.^M
main () at src/gdb/testsuite/gdb.dwarf2/main.c:1^M
1       /* This testcase is part of GDB, the GNU debugger.^M
(gdb) FAIL: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: runto: run to main
...

There are two problems here:
- the test-case contains a hardcoded "DW_LNS_advance_pc 1" which causes the
  breakpoint pointing in the middle of an insn
- the FAIL triggers on aarch64-linux, but not on x86_64-linux, because the
  test-case uses 'main_label' as the address of the first and only valid entry
  in the line table, and:
  - on aarch64-linux, there's no prologue, so main_label and main coincide,
    while
  - on x86_64-linux, there's a prologue, so main_label is different from main.

Fix these problems by:
- eliminating the use of "DW_LNS_advance_pc 1", and using
  "DW_LNE_set_address $main_end" instead, and
- eliminating the use of main_label, using "DW_LNE_set_address $main_start"
  instead.

Tested on both x86_64-linux and aarch64-linux.

cgen: increase buffer for hash_insn_list

As was done for hash_insn_array in commit d3d1cc7b13b4.

* cgen-dis.c (hash_insn_list): Increase size of buf.  Assert
size is large enough.

PR29142, segv in ar with empty archive and libdeps specified

PR 29142
* ar.c (main): Properly handle libdeps for zero file_count.

Re: IBM zSystems: Accept (. - 0x100000000) PCRel32 operands

The new test failed on s390-linux due to bfd_sprintf_vma trimming
output to 32 bits for 32-bit targets.  The test was faulty anyway,
expecting zero as the min end of the range is plainly wrong, but
that's what you get if you cast min to int.

* config/tc-s390.c (s390_insert_operand): Print range error using
PRId64.
* testsuite/gas/s390/zarch-z900-err.l: Correct expected output.

Automatic date update in version.in

[gdb/testsuite] Fix gdb.base/catch-syscall.exp with --with-expat=no

When doing a gdb build with --with-expat=no, I run into:
...
(gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \
  continue to breakpoint: before pipe call
catch syscall pipe^M
Unknown syscall name 'pipe'.^M
(gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \
  catch syscall pipe
catch syscall pipe2^M
Unknown syscall name 'pipe2'.^M
(gdb) PASS: gdb.base/catch-syscall.exp: determine pipe syscall: \
  catch syscall pipe2
continue^M
Continuing.^M
[Detaching after vfork from child process 18538]^M
[Inferior 1 (process 18537) exited normally]^M
(gdb) FAIL: gdb.base/catch-syscall.exp: determine pipe syscall: continue
...

This is a regression since recent commit 5463a15c18b ("[gdb/testsuite] Handle
pipe2 syscall in gdb.base/catch-syscall.exp").

Fix this by using pipe/pipe2 syscall numbers instead.

Tested on x86_64-linux.

nm: use -U as an alias for --defines-only, in line with llvm-nm

[gdb/testsuite] Fix gdb.base/catch-syscall.exp without --enable-targets

When doing a gdb build without --enable-targets, I run into:
...
(gdb) UNSUPPORTED: gdb.base/catch-syscall.exp: multiple targets: \
  s390:31-bit vs s390:64-bit: set architecture s390:64-bit
delete breakpoints^M
(gdb) info breakpoints^M
No breakpoints or watchpoints.^M
(gdb) break -qualified main^M
No symbol table is loaded.  Use the "file" command.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.base/catch-syscall.exp: gdb_breakpoint: set breakpoint at main
...

The problem is that due to recent commit e21d8399303 ("[gdb/testsuite] Remove
target limits in gdb.base/catch-syscall.exp") "clean_restart $binfile" no
longer is called at the end of test_catch_syscall_multi_arch.

Fix this by moving "clean_restart $binfile" back to
test_catch_syscall_multi_arch.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/maint.exp on powerpc64le

On powerpc64le-linux, I ran into:
...
FAIL: gdb.base/maint.exp: maint print objfiles: symtabs
...

The problem is that:
- the "Cooked index in use" line occurs twice in the gdb output:
  - once for exec maint, and
  - once for "Object file system-supplied DSO".
- the matching of the second "Cooked index in use" also consumes
  the "Symtabs:" string, and consequently the corresponding
  clause does not trigger and $symtabs remains 0.

Fix this by limiting the output of the command to the exec.

Tested on x86_64-linux and powerpcle-linux.

[gdb/tdep] Update syscalls/{ppc64,ppc}-linux.xml

Regenerate syscalls/{ppc64,ppc}-linux.xml on a system with 5.14 kernel.

[gdb/testsuite] Remove target limits in gdb.base/catch-syscall.exp

In test-case gdb.base/catch-syscall.exp, proc test_catch_syscall_multi_arch we
test for supported targets using istarget, like so:
...
    if { [istarget "i*86-*-*"] || [istarget "x86_64-*-*"] } {
        ...
    } elseif { [istarget "powerpc-*-linux*"] \
                  || [istarget "powerpc64*-linux*"] } {
        ...
...
but the tests excercised there can all be executed if gdb is configured with
--enable-targets=all.

Rewrite the proc to iterate over all cases, and check if the test is supported
by trying "set arch $arch1" and "set arch $arch2".

Tested on x86_64-linux, with:
- a gdb build with --enable-targets=all, and
- a gdb build build with my usual --enable-targets setting (too long to
  include here) which means the sparc vs sparc:v9 case is unsupported.

[gdb/record] Handle statx system call

When running test-case gdb.reverse/fstatat-reverse.exp with target board
unix/-m32 on openSUSE Tumbleweed, I run into:
...
(gdb) PASS: gdb.reverse/fstatat-reverse.exp: set breakpoint at marker2
continue^M
Continuing.^M
Process record and replay target doesn't support syscall number 383^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0xf7fc5555 in __kernel_vsyscall ()^M
(gdb) FAIL: gdb.reverse/fstatat-reverse.exp: continue to breakpoint: marker2
...

The problems is that while with native we're trying to record these syscalls
(showing strace output):
...
openat(AT_FDCWD, "/", O_RDONLY|O_PATH)  = 3
newfstatat(3, ".", {st_mode=S_IFDIR|0755, st_size=146, ...}, 0) = 0
...
with unix/-m32 we have instead:
...
openat(AT_FDCWD, "/", O_RDONLY|O_PATH)  = 3
statx(3, ".", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT, STATX_BASIC_STATS, \
  {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=STATX_ATTR_MOUNT_ROOT, \
  stx_mode=S_IFDIR|0755, stx_size=146, ...}) = 0
...
and statx is not supported.

Fix this by adding support for recording syscall statx.

Tested on x86_64-linux.

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

opcodes cgen: remove use of PTR

Note that opcodes is regenerated with cgen commit d1dd5fcc38e reverted,
due to failure of bpf to compile with that patch applied.

.../opcodes/bpf-opc.c:57:11: error: conversion from ‘long unsigned int’ to ‘unsigned int’ changes value from ‘18446744073709486335’ to ‘4294902015’ [-Werror=overflow]
   57 |   64, 64, 0xffffffffffff00ff, { { F (F_IMM32) }, { F (F_OFFSET16) }, { F (F_SRCLE) }, { F (F_OP_CODE) }, { F (F_DSTLE) }, { F (F_OP_SRC) }, { F (F_OP_CLASS) }, { 0 } }
plus other similar errors.

cpu/
* mep.opc (print_tpreg, print_spreg): Delete unnecessary
forward declarations.  Replace PTR with void *.
* mt.opc (print_dollarhex, print_pcrel): Delete forward decls.
opcodes/
* bpf-desc.c, * bpf-dis.c, * cris-desc.c,
* epiphany-desc.c, * epiphany-dis.c,
* fr30-desc.c, * fr30-dis.c, * frv-desc.c, * frv-dis.c,
* ip2k-desc.c, * ip2k-dis.c, * iq2000-desc.c, * iq2000-dis.c,
* lm32-desc.c, * lm32-dis.c, * m32c-desc.c, * m32c-dis.c,
* m32r-desc.c, * m32r-dis.c, * mep-desc.c, * mep-dis.c,
* mt-desc.c, * mt-dis.c, * or1k-desc.c, * or1k-dis.c,
* xc16x-desc.c, * xc16x-dis.c,
* xstormy16-desc.c, * xstormy16-dis.c: Regenerate.

Automatic date update in version.in

gdb: mips: Fix large-frame.exp test case failure

$ objdump -d outputs/gdb.base/large-frame/large-frame-O2
0000000120000b20 <func>:
   120000b20:   67bdbff0        daddiu  sp,sp,-16400
   120000b24:   ffbc4000        sd      gp,16384(sp)
   120000b28:   3c1c0002        lui     gp,0x2
   120000b2c:   679c8210        daddiu  gp,gp,-32240
   120000b30:   0399e02d        daddu   gp,gp,t9
   120000b34:   df998058        ld      t9,-32680(gp)
   120000b38:   ffbf4008        sd      ra,16392(sp)
   120000b3c:   0411ffd8        bal     120000aa0 <blah>
...

The disassembly of the above func function shows that we may use
instructions such as daddiu/daddu, so add "daddiu $gp,$gp,n",
"daddu $gp,$gp,$t9" and "daddu $gp,$t9,$gp" to the mips32_scan_prologue
function to fix the large-frame.exp test case.

Before applying the patch:

 backtrace
 #0  blah (a=0xfffffee220) at .../gdb/testsuite/gdb.base/large-frame-1.c:24
 #1  0x0000000120000b44 in func ()
 Backtrace stopped: frame did not save the PC
 (gdb) FAIL: gdb.base/large-frame.exp: optimize=-O2: backtrace

 # of expected passes            5
 # of unexpected failures        1

After applying the patch:

 # of expected passes            6

Signed-off-by: Youling Tang <tangyouling@loongson.cn>

gdb: LoongArch: Use GDB style to check readbuf and writebuf

The GDB style is to write 'if (readbuf != nullptr)', and the same for
writebuf.

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

Fix --disable-threading build

PR build/29110 points out that GDB fails to build on mingw when the
"win32" thread model is in use.  It turns out that the Fedora cross
tools using the "posix" thread model, which somehow manages to support
std::future, whereas the win32 model does not.

While looking into this, I found that the configuring with
--disable-threading will also cause a build failure.

This patch fixes this build by introducing a compatibility wrapper for
std::future.

I am not able to test the win32 thread model build, but I'm going to
ask the reporter to try this patch.

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

Fix "b f(std::string)" when current language is C

If you try to set a breakpoint at a function such as "b
f(std::string)", and the current language is C, the breakpoint fails
to be set, like so:

  (gdb) set language c
  break f(std::string)
  Function "f(std::string)" not defined.
  Make breakpoint pending on future shared library load? (y or [n]) n
  (gdb)

The problem is that the code in GDB that expands the std::string
typedef hits this in c-typeprint.c:

      /* If we have "typedef struct foo {. . .} bar;" do we want to
 print it as "struct foo" or as "bar"?  Pick the latter for
 C++, because C++ folk tend to expect things like "class5
 *foo" rather than "struct class5 *foo".  We rather
 arbitrarily choose to make language_minimal work in a C-like
 way. */
      if (language == language_c || language == language_minimal)
{
  if (type->code () == TYPE_CODE_UNION)
    gdb_printf (stream, "union ");
  else if (type->code () == TYPE_CODE_STRUCT)
    {
      if (type->is_declared_class ())
gdb_printf (stream, "class ");
      else
gdb_printf (stream, "struct ");
    }
  else if (type->code () == TYPE_CODE_ENUM)
    gdb_printf (stream, "enum ");
}

I.e., std::string is expanded to "class std::..." instead of just
"std::...", and then the "f(class std::..." symbol doesn't exist.

Fix this by making cp-support.c:inspect_type print the expanded
typedef type using the language of the symbol whose type we're
expanding the typedefs for -- in the example in question, the
"std::string" typedef symbol, which is a C++ symbol.

Use type_print_raw_options as it seems to me that in this scenario we
always want raw types, to match the real symbol names.

Adjust the gdb.cp/break-f-std-string.exp testcase to try setting a
breakpoint at "f(std::string)" in both C and C++.

Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b

Always pass an explicit language down to c_type_print

The next patch will want to do language->print_type(type, ...), to
print a type in a given language, avoiding a dependency on the current
language.  That doesn't work correctly currently, however, because
most language implementations of language_defn::print_type call
c_print_type without passing down the language.  There are two
overloads of c_print_type, one that takes a language, and one that
does not.  The one that does not uses the current language, defeating
the point of calling language->print_type()...

This commit removes the c_print_type overload that does not take a
language, and adjusts the codebase throughout to always pass down a
language.  In most places, there's already an enum language handy.
language_defn::print_type implementations naturally pass down
this->la_language.  In a couple spots, like in ada-typeprint.c and
rust-lang.c there's no enum language handy, but the code is written
for a specific language, so we just hardcode the language.

In gnuv3_print_method_ptr, I wasn't sure whether we could hardcode C++
here, and we don't have an enum language handy, so I made it use the
current language, just like today.  Can always be improved later.

Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b

Fix "b f(std::string)", always use DMGL_VERBOSE

Currently, on any remotely modern GNU/Linux system,
gdb.cp/no-dmgl-verbose.exp fails like so:

  break 'f(std::string)'
  Function "f(std::string)" not defined.
  (gdb) FAIL: gdb.cp/no-dmgl-verbose.exp: gdb_breakpoint: set breakpoint at 'f(std::string)'
  break 'f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)'
  Function "f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)" not defined.
  (gdb) PASS: gdb.cp/no-dmgl-verbose.exp: DMGL_VERBOSE-demangled f(std::string) is not defined

This testcase was added back in 2011, here:

  [patch] Remove DMGL_VERBOSE
  https://sourceware.org/pipermail/gdb-patches/2011-June/083081.html

Back then, the testcase would pass cleanly.  It turns out that the
reason it fails today is that the testcase is exercising something in
GDB that only makes sense if the program is built for the pre-C++11
libstc++ ABI.  Back then the C++11 ABI didn't exist yet, but nowadays,
you need to compile with -D_GLIBCXX_USE_CXX11_ABI=0 to use the old
ABI.  See "Dual ABI" in the libstdc++ manual, at
<https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html>.

If we tweak the gdb.cp/no-dmgl-verbose.exp testcase to force the old
ABI with -D_GLIBCXX_USE_CXX11_ABI=0, then it passes cleanly.

So why is it that setting a breakpoint at "f(std::string)" fails with
modern ABI, but passes with old ABI?

This is where libiberty demangler's DMGL_VERBOSE option comes in.  The
Itanium ABI mangling scheme has a shorthand form for std::string (and
some other types).  See
<https://itanium-cxx-abi.github.io/cxx-abi/abi.html>:

  "In addition, the following catalog of abbreviations of the form "Sx" are used:

     <substitution> ::= St # ::std::
     <substitution> ::= Sa # ::std::allocator
     <substitution> ::= Sb # ::std::basic_string
     <substitution> ::= Ss # ::std::basic_string < char,
   ::std::char_traits<char>,
   ::std::allocator<char> >
     <substitution> ::= Si # ::std::basic_istream<char,  std::char_traits<char> >
     <substitution> ::= So # ::std::basic_ostream<char,  std::char_traits<char> >
     <substitution> ::= Sd # ::std::basic_iostream<char, std::char_traits<char> >
  "

When the libiberty demangler encounters such a abbreviation, by
default, it expands it to the user-friendly typedef "std::string",
"std::iostream", etc..  If OTOH DMGL_VERBOSE is specified, the
abbreviation is expanded to the underlying, non-typedefed fullname
"std::basic_string<char, std::char_traits<char>, std::allocator<char> >"
etc. as documented in the Itanium ABI, and pasted above.  You can see
the standard abbreviations/substitutions in
libiberty/cp-demangle.c:standard_subs.

Back before Jan's patch in 2011, there were parts of GDB that used
DMGL_VERBOSE, and others that did not, leading to mismatches.  The
solution back then was to stop using DMGL_VERBOSE throughout.

GDB has code in place to let users set a breakpoint at a function with
typedefs in its parameters, like "b f(uint32_t)".  Demangled function
names as they appear in the symbol tables almost (more on this is in a
bit) never have typedefs in them, so when processing "b f(uint32_t)"
GDB first replaces "uint32_t" for its underlying type, and then sets a
breakpoint on the resulting prototype, in this case "f(unsigned int)".

Now, if DMGL_VERBOSE is _not_ used, then the demangler demangles the
mangled name of a function such as "void f(std::string)" that was
mangled using the standard abbreviations mentioned above really as:

  "void f(std::string)".

For example, the mangled name of "void f(std::string)" if you compile
with old pre-C++11 ABI is "_Z1fSs".  That uses the abbreviation "Ss",
so if you demangle that without DMGL_VERBOSE, you get:

  $ echo "_Z1fSs" | c++filt --no-verbose
  f(std::string)

while with DMGL_VERBOSE you'd get:

  $ echo "_Z1fSs" | c++filt
  f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)

If, when the user sets a breakpoint at "f(std::string)", GDB would
replace the std::string typedef for its underlying type using the same
mechanism I mentioned for the "f(uint32_t)" example above, then GDB
would really try to set a breakpoint at "f(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >)", and that would fail,
as the function symbol GDB knows about for that function, given no
DMGL_VERBOSE, is "f(std::string)".

For this reason, the code that expands typedefs in function parameter
names has an exception for std::string (and other standard
abbreviation types), such that "std::string" is never
typedef-expanded.

And here lies the problem when you try to do "b f(std::string)" with a
program compiled with the C++11 ABI.  In that case, std::string
expands to a different underlying type, like so:

  f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)

and this symbol naturally mangles differently, as:

  _Z1fNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE

and then because this doesn't use the shorthand mangling abbreviation
for "std::string" anymore, it always demangles as:

  f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)

Now, when using the C++11 ABI, and you set a breakpoint at
"f(std::string)", GDB's typedefs-in-parameters expansion code hits the
exception for "std::string" and doesn't expand it, so the breakpoint
fails to be inserted, because the symbol that exists is really the

  f(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >)

one, not "f(std::string)".

So to fix things for C++11 ABI, clearly we need to remove the
"std::string" exception from the typedef-in-parameters expansion
logic.  If we do just that, then "b f(std::string)" starts working
with the C++11 ABI.

However, if we do _just_ that, and nothing else, then we break
pre-C++11 ABI...

The solution is then to in addition switch GDB to always use
DMGL_VERBOSE.  If we do this, then pre-C++11 ABI symbols works the
same as C++11 ABI symbols overall -- the demangler expands the
standard abbreviation for "std::string" as "std::basic_string<char,
std::char_traits<char>, std::allocator<char> >" and letting GDB expand
the "std::string" typedef (etc.) too is no longer a problem.

To avoid getting in the situation where some parts of GDB use
DMGL_VERBOSE and others not, this patch adds wrappers around the
demangler's entry points that GDB uses, and makes those force
DMGL_VERBOSE.

The point of the gdb.cp/no-dmgl-verbose.exp testcase was to try to
ensure that DMGL_VERBOSE doesn't creep back in:

 gdb_test {break 'f(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)'} \
  {Function ".*" not defined\.} \
  "DMGL_VERBOSE-demangled f(std::string) is not defined"

This obviously no longer makes sense to have, since we now depend on
DMGL_VERBOSE.  So the patch replaces gdb.cp/no-dmgl-verbose.exp with a
new gdb.cp/break-f-std-string.exp testcase whose purpose is to make
sure that setting a breakpoint at "f(std::string)" works.  It
exercises both pre-C++11 ABI and C++11 ABI.

Change-Id: Ib54fab4cf0fd307bfd55bf1dd5056830096a653b