gdb: remove SYMTAB_LANGUAGE macro, add getter/setter

Add a getter and a setter for a symtab's language.  Remove the
corresponding macro and adjust all callers.

Change-Id: I9f4d840b11c19f80f39bac1bce020fdd1739e11f

gdb: remove SYMTAB_LINETABLE macro, add getter/setter

Add a getter and a setter for a symtab's linetable.  Remove the
corresponding macro and adjust all callers.

Change-Id: I159183fc0ccd8e18ab937b3c2f09ef2244ec6e9c

gdb: remove SYMTAB_COMPUNIT macro, add getter/setter

Add a getter and a setter for a symtab's compunit_symtab.  Remove the
corresponding macro and adjust all callers.

For brevity, I chose the name "compunit" instead of "compunit_symtab"
the the field, getter and setter names.  Since we are already in symtab
context, the _symtab suffix seems redundant.

Change-Id: I4b9b731c96e3594f7733e75af1e3d01bc0e4fe92

gdb: remove COMPUNIT_MACRO_TABLE macro, add getter/setter

Add a getter and a setter for a compunit_symtab's macro table.  Remove the
corresponding macro and adjust all callers.

Change-Id: I00615ea72d5ac43d9a865e941cb2de0a979c173a

gdb: remove COMPUNIT_EPILOGUE_UNWIND_VALID macro, add getter/setter

Add a getter and a setter for a compunit_symtab's epilogue unwind valid flag.
Remove the corresponding macro and adjust all callers.

Change-Id: If3b68629d987767da9be7041a95d96dc34367a9a

gdb: remove COMPUNIT_LOCATIONS_VALID macro, add getter/setter

Add a getter and a setter for a compunit_symtab's locations valid flag.
Remove the corresponding macro and adjust all callers.

Change-Id: I3e3cfba926ce62993d5b61814331bb3244afad01

gdb: remove COMPUNIT_BLOCK_LINE_SECTION macro, add getter/setter

Add a getter and a setter for a compunit_symtab's block line section.  Remove
the corresponding macro and adjust all callers.

Change-Id: I3eb1a323388ad55eae8bfa45f5bc4a08dc3df455

gdb: remove COMPUNIT_BLOCKVECTOR macro, add getter/setter

Add a getter and a setter for a compunit_symtab's blockvector.  Remove
the corresponding macro and adjust all callers.

Change-Id: I99484c6619dcbbea7c5d89c72aa660316ca62f64

gdb: remove COMPUNIT_DIRNAME macro, add getter/setter

Add a getter and a setter for a compunit_symtab's dirname.  Remove the
corresponding macro and adjust all callers.

Change-Id: If2f39b295fd26822586485e04a8b8b5aa5cc9b2e

gdb: remove COMPUNIT_PRODUCER macro, add getter/setter

Add a getter and a setter for a compunit_symtab's producer.  Remove the
corresponding macro and adjust all callers.

Change-Id: Ia1d6d8a0e247a08a21af23819d71e49b37d8931b

gdb: remove COMPUNIT_DEBUGFORMAT macro, add getter/setter

Add a getter and a setter for a compunit_symtab's debugformat.  Remove
the corresponding macro and adjust all callers.

Change-Id: I1667b02d5322346f8e23abd9f8a584afbcd75975

gdb: remove COMPUNIT_FILETABS macro

I think that most remaining uses of COMPUNIT_FILETABS intend to get the
primary filetab of the compunit_symtab specifically (and not to iterate
over all filetabs, for example, those cases would use compunit_filetabs,
which has been converted to compunit_symtab::filetabs), so replace mosts
uses with compunit_symtab::primary_filetab.

In jit.c, function finalize_symtab, we can save the symtab object
returned by allocate_symtab and use it, it makes things simpler.

Change-Id: I4e51d6d4b40759de8768b61292e5e13c8eae2e38

gdb: move compunit_filetabs to compunit_symtab::filetabs

Make compunit_filetabs, used to iterate a compunit_symtab's filetabs, a
method of compunit_symtab.  The name filetabs conflicts with the current
name of the field.  Rename the field to m_filetabs, since at this point
nothing outside of compunit_symtab uses it, so we should treat it as
private (even though it's not actually private).  Rename the
last_filetab field to m_last_filetab as well (it's only used on
compunit_symtab::add_filetab).

Adjust the COMPUNIT_FILETABS macro to keep its current behavior of
returning the first filetab.

Change-Id: I537b553a44451c52d24b18ee1bfa47e23747cfc3

gdb: add compunit_symtab::set_primary_filetab method

Add a method to set the primary filetab of the CU.  This is currently
done in buildsym_compunit::end_symtab_with_blockvector.

Change-Id: I16c51a6b90a4cb4c0c5f183b0f2e12bc64b6fd74

gdb: add compunit_symtab::add_filetab method

Add a method to append a filetab/symtab to a compunit_symtab.  There is
a single place where this is done currently, in allocate_symtab.

Change-Id: Ie86c6e34d175728173d1cffdce44acd6cff6c31d

gdb: rename compunit_primary_filetab to compunit_symtab::primary_filetab

Make compunit_primary_filetab a method of compunit_symtab.

Change-Id: Iee3c4f7e36d579bf763c5bba146e5e10d6766768

gdb: remove COMPUNIT_OBJFILE macro

Remove the macro, update all users to use the getter directly.

Change-Id: I3f0fd6f4455d1c4ebd5da73b561eb18a979ef1f6

gdb: add getter/setter for compunit_symtab::objfile

Rename the field to m_objfile, and add a getter and a setter.  Update
all users.

Change-Id: If7e2f763ee3e70570140d9af9261b1b056253317

Allow non-ASCII characters in Rust identifiers

Rust 1.53 (quite a while ago now) ungated the support for non-ASCII
identifiers.  This didn't work in gdb.  This is PR rust/20166.

This patch fixes the problem by allowing non-ASCII characters to be
considered as identifier components.  It seemed simplest to just pass
them through -- doing any extra checking didn't seem worthwhile.

The new test also verifies that such characters are allowed in strings
and character literals as well.  The latter also required a bit of
work in the lexer.

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

Fix Rust parser bug with function fields

In Rust, 'obj.f()' is a method call -- but '(obj.f)()' is a call of a
function-valued field 'f' in 'obj'.  The Rust parser in gdb currently
gets this wrong.  This is PR rust/24082.

The expression and Rust parser rewrites made this simple to fix --
simply wrapping a parenthesized expression in a new operation handles
it.  This patch has a slight hack because I didn't want to introduce a
new exp_opcode enumeration constant just for this.  IMO this doesn't
matter, since we should work toward removing dependencies on these
opcodes anyway; but let me know what you think of this.

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

ld: Add emultempl/emulation.em

Add emultempl/emulation.em to define ld_${EMULATION_NAME}_emulation so
that new emulation hooks can be added easily.

* emultempl/aix.em (LDEMUL_AFTER_OPEN): New.
(LDEMUL_SET_OUTPUT_ARCH): Likewise.
(LDEMUL_CHOOSE_TARGET): Likewise.
(LDEMUL_BEFORE_ALLOCATION): Likewise.
(LDEMUL_CREATE_OUTPUT_SECTION_STATEMENTS): Likewise.
(LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise.
(LDEMUL_PARSE_ARGS): Likewise.
(LDEMUL_ADD_OPTIONS): Likewise.
(LDEMUL_HANDLE_OPTION): Likewise.
(LDEMUL_UNRECOGNIZED_FILE): Likewise.
(LDEMUL_PRINT_SYMBOL): Likewise.
(ld_${EMULATION_NAME}_emulation): Removed.
Source ${srcdir}/emultempl/emulation.em.
* emultempl/beos.em (gld_${EMULATION_NAME}_before_parse):
Renamed to ...
(gld${EMULATION_NAME}_before_parse): This.
(gld_${EMULATION_NAME}_set_symbols): Renamed to ...
(gld${EMULATION_NAME}_set_symbols): This.
(gld_${EMULATION_NAME}_after_open): Renamed to ...
(gld${EMULATION_NAME}_after_open): This.
(gld_${EMULATION_NAME}_before_allocation): Renamed to ...
(gld${EMULATION_NAME}_before_allocation): This.
(gld_${EMULATION_NAME}_get_script): Renamed to ...
(gld${EMULATION_NAME}_get_script): This.
(LDEMUL_AFTER_OPEN): New.
(LDEMUL_BEFORE_ALLOCATION): Likewise.
(LDEMUL_PLACE_ORPHAN): Likewise.
(LDEMUL_SET_SYMBOLS): Likewise.
(LDEMUL_ADD_OPTIONS): Likewise.
(LDEMUL_HANDLE_OPTION): Likewise.
(ld_${EMULATION_NAME}_emulation): Removed.
Source ${srcdir}/emultempl/emulation.em.
* emultempl/elf.em (LDEMUL_AFTER_PARSE): New.
(LDEMUL_AFTER_OPEN): Likewise.
(LDEMUL_BEFORE_PLACE_ORPHANS): Likewise.
(LDEMUL_AFTER_ALLOCATION): Likewise.
(LDEMUL_SET_OUTPUT_ARCH): Likewise.
(LDEMUL_BEFORE_ALLOCATION): Likewise.
(LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise.
(LDEMUL_PLACE_ORPHAN): Likewise.
(LDEMUL_ADD_OPTIONS): Likewise.
(LDEMUL_HANDLE_OPTION): Likewise.
(LDEMUL_LIST_OPTIONS): Likewise.
(LDEMUL_UNRECOGNIZED_FILE): Likewise.
(ld_${EMULATION_NAME}_emulation): Removed.
Source ${srcdir}/emultempl/emulation.em.
* emultempl/emulation.em: New file.
* emultempl/generic.em (ld_${EMULATION_NAME}_emulation): Removed.
Source ${srcdir}/emultempl/emulation.em.
* emultempl/msp430.em (LDEMUL_AFTER_OPEN): New.
(LDEMUL_AFTER_ALLOCATION): Likewise.
(LDEMUL_PLACE_ORPHAN): Likewise.
(LDEMUL_FINISH): Likewise.
(LDEMUL_ADD_OPTIONS): Likewise.
(LDEMUL_HANDLE_OPTION): Likewise.
(LDEMUL_LIST_OPTIONS): Likewise.
(ld_${EMULATION_NAME}_emulation): Removed.
Source ${srcdir}/emultempl/emulation.em.
* emultempl/pe.em (gld_${EMULATION_NAME}_before_parse): Renamed
to ...
(gld${EMULATION_NAME}_before_parse): This.
(gld_${EMULATION_NAME}_list_options): Renamed to ...
(gld${EMULATION_NAME}_list_options): This.
(gld_${EMULATION_NAME}_set_symbols): Renamed to ...
(gld${EMULATION_NAME}_set_symbols): This.
(gld_${EMULATION_NAME}_after_parse): Renamed to ...
(gld${EMULATION_NAME}_after_parse): This.
(gld_${EMULATION_NAME}_after_open): Renamed to ...
(gld${EMULATION_NAME}_after_open): This.
(gld_${EMULATION_NAME}_before_allocation): Renamed to ...
(gld${EMULATION_NAME}_before_allocation): This.
(gld_${EMULATION_NAME}_unrecognized_file): Renamed to ...
(gld${EMULATION_NAME}_unrecognized_file): This.
(gld_${EMULATION_NAME}_recognized_file): Renamed to ...
(gld${EMULATION_NAME}_recognized_file): This.
(gld_${EMULATION_NAME}_finish): Renamed to ...
(gld${EMULATION_NAME}_finish): This.
(gld_${EMULATION_NAME}_place_orphan): Renamed to ...
(gld${EMULATION_NAME}_place_orphan): This.
(gld_${EMULATION_NAME}_open_dynamic_archive): Renamed to ...
(gld${EMULATION_NAME}_open_dynamic_archive): This.
(gld_${EMULATION_NAME}_find_potential_libraries): Renamed to ...
(gld${EMULATION_NAME}_find_potential_libraries): This.
(gld_${EMULATION_NAME}_get_script): Renamed to ...
(gld${EMULATION_NAME}_get_script): This.
(LDEMUL_AFTER_PARSE): New.
(LDEMUL_AFTER_OPEN): Likewise.
(LDEMUL_BEFORE_ALLOCATION): Likewise.
(LDEMUL_FINISH=): Likewise.
(LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise.
(LDEMUL_PLACE_ORPHAN): Likewise.
(LDEMUL_SET_SYMBOLS): Likewise.
(LDEMUL_ADD_OPTIONS): Likewise.
(LDEMUL_HANDLE_OPTION): Likewise.
(LDEMUL_UNRECOGNIZED_FILE): Likewise.
(LDEMUL_LIST_OPTIONS): Likewise.
(LDEMUL_RECOGNIZED_FILE): Likewise.
(LDEMUL_FIND_POTENTIAL_LIBRARIES): Likewise.
(ld_${EMULATION_NAME}_emulation): Removed.
Source ${srcdir}/emultempl/emulation.em.
* emultempl/pep.em (gld_${EMULATION_NAME}_before_parse): Renamed
to ...
(gld${EMULATION_NAME}_before_parse): This.
(gld_${EMULATION_NAME}_list_options): Renamed to ...
(gld${EMULATION_NAME}_list_options): This.
(gld_${EMULATION_NAME}_set_symbols): Renamed to ...
(gld${EMULATION_NAME}_set_symbols): This.
(gld_${EMULATION_NAME}_after_parse): Renamed to ...
(gld${EMULATION_NAME}_after_parse): This.
(gld_${EMULATION_NAME}_after_open): Renamed to ...
(gld${EMULATION_NAME}_after_open): This.
(gld_${EMULATION_NAME}_before_allocation): Renamed to ...
(gld${EMULATION_NAME}_before_allocation): This.
(gld_${EMULATION_NAME}_unrecognized_file): Renamed to ...
(gld${EMULATION_NAME}_unrecognized_file): This.
(gld_${EMULATION_NAME}_recognized_file): Renamed to ...
(gld${EMULATION_NAME}_recognized_file): This.
(gld_${EMULATION_NAME}_finish): Renamed to ...
(gld${EMULATION_NAME}_finish): This.
(gld_${EMULATION_NAME}_place_orphan): Renamed to ...
(gld${EMULATION_NAME}_place_orphan): This.
(gld_${EMULATION_NAME}_open_dynamic_archive): Renamed to ...
(gld${EMULATION_NAME}_open_dynamic_archive): This.
(gld_${EMULATION_NAME}_find_potential_libraries): Renamed to ...
(gld${EMULATION_NAME}_find_potential_libraries): This.
(gld_${EMULATION_NAME}_get_script): Renamed to ...
(gld${EMULATION_NAME}_get_script): This.
(LDEMUL_AFTER_PARSE): New.
(LDEMUL_AFTER_OPEN): Likewise.
(LDEMUL_BEFORE_ALLOCATION): Likewise.
(LDEMUL_FINISH=): Likewise.
(LDEMUL_OPEN_DYNAMIC_ARCHIVE): Likewise.
(LDEMUL_PLACE_ORPHAN): Likewise.
(LDEMUL_SET_SYMBOLS): Likewise.
(LDEMUL_ADD_OPTIONS): Likewise.
(LDEMUL_HANDLE_OPTION): Likewise.
(LDEMUL_UNRECOGNIZED_FILE): Likewise.
(LDEMUL_LIST_OPTIONS): Likewise.
(LDEMUL_RECOGNIZED_FILE): Likewise.
(LDEMUL_FIND_POTENTIAL_LIBRARIES): Likewise.
(ld_${EMULATION_NAME}_emulation): Removed.
Source ${srcdir}/emultempl/emulation.em.
* emultempl/ticoff.em (gld_${EMULATION_NAME}_list_options):
Renamed to ...
(gld${EMULATION_NAME}_list_options): This.
(gld_${EMULATION_NAME}_before_parse): Renamed to ...
(gld_${EMULATION_NAME}_get_script): Renamed to ...
(gld${EMULATION_NAME}_get_script): This.
(LDEMUL_ADD_OPTIONS): New.
(LDEMUL_HANDLE_OPTION): Likewise.
(LDEMUL_LIST_OPTIONS): Likewise.
(ld_${EMULATION_NAME}_emulation): Removed.
Source ${srcdir}/emultempl/emulation.em.
* emultempl/vanilla.em (LDEMUL_BEFORE_PARSE): New.
(LDEMUL_SET_OUTPUT_ARCH): Likewise.
(LDEMUL_GET_SCRIPT): Likewise.
(EMULATION_NAME): Likewise.
(OUTPUT_FORMAT): Likewise.
(ld_vanilla_emulation): Removed.
Source ${srcdir}/emultempl/emulation.em.

gdb/doc: update docs for 'info win' and 'winheight' commands

This started by noticing that the docs for 'winheight' are out of
date, the docs currently give a specific list of possible window
names.  However, now that windows can be implemented in Python, it is
not possible to list all possible names.

I now link the user to a mechanism by which they can discover the
valid names for themselves at run time (by using 'info win').  That,
and the fact that gdb provides tab-completion of the name at the
command line, feels good enough.

Finally, I noticed that the docs for 'win info' don't explicitly say
that the name of the window is given in the output.  This could
probably have been inferred, but given I'm now linking to this as a
mechanism to find the window name, I'd prefer to mention that the name
can be found in the output.

gdb/tui: add window width information to 'info win' output

Now that we support horizontal window placement in the tui, it makes
sense to have 'info win' include the width, as well as the height, of
the currently visible windows.

That's what this commit does.  Example output is now:

  (gdb) info win
  Name       Lines Columns Focus
  src           12      40 (has focus)
  asm           12      41
  status         1      80
  cmd           11      80

I've added a NEWS entry, but the documentation was already suitably
vague, it just says that 'info win' displays the size of the visible
windows, so I don't think anything needs to be added there.

I've also added some tests, as far as I could find, the 'info win'
command was previously untested.

Automatic date update in version.in

x86: Skip undefined symbol when finishing DT_RELR

Don't abort for undefined symbol when finishing DT_RELR.  Instead, skip
undefined symbol.  Undefined symbol will be reported by relocate_section.

* elfxx-x86.c (elf_x86_size_or_finish_relative_reloc): Skip
undefined symbol in finishing phase.

Tweak assembler invocation for pr28827-1 test

PR 28827
* testsuite/ld-powerpc/pr28827-1.d: Pass -a64 to gas.

PR28827 testcase

This testcase triggers a stub sizing error with the patches applied
for PR28743 (commit 2f83249c13d8 and c804c6f98d34).

PR 28827
* testsuite/ld-powerpc/pr28827-1.s,
* testsuite/ld-powerpc/pr28827-1.d: New test.
* testsuite/ld-powerpc/powerpc.exp: Run it.

Enable "size" as a dumpprog in ld

binutils/
* testsuite/lib/binutils-common.exp (run_dump_test): Reference
global SIZE and SIZEFLAGS.
ld/
* testsuite/config/default.exp: Define SIZE and SIZEFLAGS.

Detect .eh_frame_hdr earlier for SIZEOF_HEADERS

Current code detects the need for PT_GNU_EH_FRAME using a field set by
_bfd_elf_discard_section_eh_frame_hdr, which is called fairly late in
the linking process.  Use the elf hash table eh_info instead, which is
set up earlier by size_dynamic_sections.

* elf-bfd.h (struct output_elf_obj_tdata): Delete eh_frame_hdr.
(elf_eh_frame_hdr): Don't define.
(_bfd_elf_discard_section_eh_frame_hdr): Update prototype.
* elf-eh-frame.c (_bfd_elf_discard_section_eh_frame_hdr): Delete
abfd parameter.  Don't set elf_eh_frame_hdr.
* elf.c (elf_eh_frame_hdr): New function.
(get_program_header_size): Adjust elf_eh_frame_hdr call.
(_bfd_elf_map_sections_to_segments): Likewise.

sim: mips: Add simulator support for mips32r6/mips64r6

2022-02-01  Ali Lown  <ali.lown@imgtec.com>
    Andrew Bennett  <andrew.bennett@imgtec.com>
    Dragan Mladjenovic  <dragan.mladjenovic@rt-rk.com>
    Faraz Shahbazker  <fshahbazker@wavecomp.com>

sim/common/ChangeLog:
* sim-bits.h (EXTEND9, EXTEND18 ,EXTEND19, EXTEND21,
EXTEND26): New macros.

sim/mips/ChangeLog:
* Makefile.in (IGEN_INCLUDE): Add mips3264r6.igen.
* configure: Regenerate.
* configure.ac: Support mipsisa32r6 and mipsisa64r6.
(sim_engine_run): Pick simulator model from processor specified
in e_flags.
* cp1.c (value_fpr): Handle fmt_dc32.
(fp_unary, fp_binary): Zero initialize locals.
(update_fcsr, fp_classify, fp_rint, fp_r6_cmp, inner_fmac,
fp_fmac, fp_min, fp_max, fp_mina, fp_maxa, fp_fmadd, fp_fmsub):
New functions.
(sim_fpu_class_mips_mapping): New.
* cp1.h (fcsr_ABS2008_mask, fcsr_ABS2008_shift): New define.
* interp.c (MIPSR6_P): New.
(load_word): Allow unaligned memory access for MIPSR6.
* micromips.igen (sc, scd): Adapt to new do_sc* helper signature.
* mips.igen: Add *r6 models.
(signal_if_cti, forbiddenslot32): New helpers.
(delayslot32): Use signal_if_cti.
(do_sc, do_scd); Add store_ll_bit parameter.
(sc, scd): Adapt to previous change.
(nal, beq, bal): New definitions for *r6.
(sll): Split nop and ssnop cases into ...
(nop, ssnop): New definitions.
(loadstore_ea): Use the 32-bit compatibility adressing.
(cache): Split logic into ...
(do_cache): New helper.
(check_fpu): Select IEEE 754-2008 mode for R6.
(not_word_value, unpredictable, check_mt_hilo, check_mf_hilo,
check_multi_hilo, check_div_hilo, check_u64, do_dmfc1b, add,
li, addu, and, andi, bgez, bgtz, blez, bltz, bne, break, dadd,
daddiu, daddu, dror, dror32, drorv, dsll, dsll32, dsllv, dsra,
dsra32, dsrav, dsrl, dsrl32, dsub, dsubu, j, jal, jalr,
jalr.hb, lb, lbu, ld, lh, lhu, lui, lw, lwu, nor, or, ori, ror,
rorv, sb, sd, sh, sll, sllv, slt, slti, sltiu, sltu, sra, srav,
srl, srlv, sub, subu, sw, sync, syscall, teq, tge, tgeu, tlt,
tltu, tne, xor, xori, check_fmt_p, do_load_double,
do_store_double, abs.FMT, add.FMT, ceil.l.FMT, ceil.w.FMT,
cfc1, ctc1, cvt.d.FMT, cvt.l.FMT, cvt.w.FMT, div.FMT, dfmc1,
dmtc1, floor.l.FMT, floor.w.FMT, ldc1, lwc1, mfc1, mov.FMT,
mtc1, mul.FMT, recip.FMT, round.l.FMT, round.w.FMT, rsqrt.FMT,
sdc1, sqrt.FMT, sub.FMT, swc1, trunc.l.FMT, trunc.w.FMT, bc0f,
bc0fl, bc0t, bc0tl, dmfc0, dmtc0, eret, mfc0, mtc0, cop, tlbp,
tlbr, tlbwi, tlbwr): Enable on *r6 models.
* mips3264r2.igen (dext, dextm, dextu, di, dins, dinsm, dinsu,
dsbh, dshd, ei, ext, mfhc1, mthc1, ins, seb, seh, synci, rdhwr,
wsbh): Likewise.
* mips3264r6.igen: New file.
* sim-main.h (FP_formats): Add fmt_dc32.
(FORBIDDEN_SLOT): New macros.
(simFORBIDDENSLOT, FP_R6CMP_*, FP_R6CLASS_*): New defines.
(fp_r6_cmp, fp_classify, fp_rint, fp_min, fp_max, fp_mina,
fp_maxa, fp_fmadd, fp_fmsub): New declarations.
(R6Compare, Classify, RoundToIntegralExact, Min, Max, MinA,
MaxA, FusedMultiplyAdd, FusedMultiplySub): New macros. Wrapping
previous declarations.

sim/testsuite/mips/ChangeLog:
* basic.exp: Add r6-*.s tests.
(run_r6_removed_test): New function.
(run_endian_tests): New function.
* hilo-hazard-3.s: Skip for mips*r6.
* r2-fpu.s: New test.
* r6-64.s: New test.
* r6-branch.s: New test.
* r6-forbidden.s: New test.
* r6-fpu.s: New test.
* r6-llsc-dp.s: New test.
* r6-llsc-wp.s: New test.
* r6-removed.csv: New test.
* r6-removed.s: New test.
* r6.s: New test.
* utils-r6.inc: New inc.

sim: Add partial support for IEEE 754-2008

2022-02-01  Faraz Shahbazker  <fshahbazker@wavecomp.com>

sim/common/ChangeLog:
* sim-fpu.c (sim_fpu_minmax_nan): New.
(sim_fpu_max): Add variant behaviour for IEEE 754-2008.
(sim_fpu_min): Likewise.
(sim_fpu_is_un, sim_fpu_is_or): New.
(sim_fpu_un, sim_fpu_or): New.
(sim_fpu_is_ieee754_2008, sim_fpu_is_ieee754_1985): New.
(sim_fpu_set_mode): New.
(sim_fpu_classify): New.
* sim-fpu.h (sim_fpu_minmax_nan): New declaration.
(sim_fpu_un, sim_fpu_or): New declarations.
(sim_fpu_is_un, sim_fpu_is_or): New declarations.
(sim_fpu_mode): New enum.
[sim_fpu_state](current_mode): New field.
(sim_fpu_current_mode): New define.
(sim_fpu_is_ieee754_2008): New declaration.
(sim_fpu_is_ieee754_1985): New declaration.
(sim_fpu_set_mode): New declaration.
(sim_fpu_classify): New declaration.

sim: Factor out NaN handling in floating point operations

2022-02-01  Faraz Shahbazker  <fshahbazker@wavecomp.com>

sim/common/ChangeLog:
* sim-fpu.c (sim_fpu_op_nan): New.
(sim_fpu_add): Factor out NaN operand handling with
a call to sim_fpu_op_nan.
(sim_fpu_sub, sim_fpu_mul, sim_fpu_div): Likewise.
(sim_fpu_rem, sim_fpu_max, sim_fpu_min): Likewise.
* sim-fpu.h (sim_fpu_op_nan): New declaration.

sim: Allow toggling of quiet NaN-bit semantics

IEEE754-1985 specifies the top bit of the mantissa as an indicator
of signalling vs. quiet NaN, but does not define the precise semantics.
Most architectures treat this bit as indicating quiet NaN, but legacy
(pre-R6) MIPS goes the other way and treats it as signalling NaN.

This used to be controlled by a macro that was only defined for MIPS.
This patch replaces the macro with a variable to track the current
semantics of the NaN bit and allows differentiation between older
(pre-R6) and and newer MIPS cores.

2022-02-01  Faraz Shahbazker  <fshahbazker@wavecomp.com>

sim/common/ChangeLog:
* sim-fpu.c (_sim_fpu): New.
(pack_fpu, unpack_fpu): Allow reversal of quiet NaN semantics.
* sim-fpu.h (sim_fpu_state): New struct.
(_sim_fpu): New extern.
(sim_fpu_quiet_nan_inverted): New define.

sim/mips/ChangeLog:
* cp1.h (fcsr_NAN2008_mask, fcsr_NAN2008_shift): New.
* mips.igen (check_fpu): Select default quiet NaN mode
for legacy MIPS.
* sim-main.h (SIM_QUIET_NAN_NEGATED): Remove.

Automatic date update in version.in

ld: Remove emultempl/armcoff.em

Remove emultempl/armcoff.em which has been unused after

commit 2ac93be706418f3b2aebeb22159a328023faed52
Author: Alan Modra <amodra@gmail.com>
Date:   Mon Apr 16 20:33:36 2018 +0930

    Remove arm-aout and arm-coff support

    This also removes arm-netbsd (not arm-netbsdelf!), arm-openbsd, and
    arm-riscix.  Those targets weren't on the obsolete list but they are
    all aout, and it doesn't make all that much sense to remove arm-aout
    without removing them too.

* emultempl/armcoff.em: Removed.

gdb: include jit_code_entry::symfile_addr value in names of objfiles created by jit reader API

This commit includes the JIT object's symfile address in the names of
objfiles created by JIT reader API (e.g., << JIT compiled code at
0x7ffd8a0c77a0 >>).  This allows one to at least differentiate one from
another.

The address is the one that the debugged program has put in
jit_code_entry::symfile_addr, and that the JIT reader's read function
receives.  As we can see in gdb.base/jit-reader-host.c and
gdb.base/jit-reader.c, that may not be the actual value of where the
JIT-ed code is.  But it is a value chosen by the author of the JIT
engine and the JIT reader, so including this value in the objfile name
may help them correlate the JIT objfiles created by with their logs /
data structures.

To access this field, we need to pass down a reference to the
jit_code_entry.  So make jit_dbg_reader_data a structure (instead of an
alias for a CORE_ADDR) that includes the address of the code entry in
the inferior's address space (the previous meaning of
jit_dbg_reader_data) plus a reference to the jit_code_entry as read into
GDB's address space.  And while at it, pass down the gdbarch, so that we
don't have to call target_gdbarch.

Co-Authored-By: Jan Vrany <jan.vrany@labware.com>
Change-Id: Ib26c4d1bd8de503d651aff89ad2e500cb312afa5

Improve Ada unchecked union type printing

Currently, "ptype" of an Ada unchecked union may show a
compiler-generated wrapper structure in its output.  It's more
Ada-like to elide this structure, which is what this patch implements.
It turned out to be simplest to reuse a part of print_variant_clauses
for this.

As this is Ada-specific, and Joel already reviewed it internally, I am
going to check it in.

Remove host_hex_value

I noticed that host_hex_value is redundant, because gdbsupport already
has fromhex.  This patch removes the former in favor of the latter.

Regression tested on x86-64 Fedora 34.

Support symbol+offset lookup in addr2line

The Linux kernel usually ouputs symbol+offset instead of plain code
addresses these days, to avoid leaking ASLR secrets and to handle
dynamically loaded modules.

Converting those with addr2line is somewhat involved: it requires
looking up the symbol first using nm and then manually compute the
offset, and then pass it to addr2line.

This patch implements the necessary steps directly in addr2line,
by looking up the symbol (with demangling if needed) and computing
the offset.

It's possible that a symbol is ambigious with a hex number. In this
case it uses the symbol lookup if the string contains a +. When it isn't
ambigious the + is optional.

Automatic date update in version.in

Rename EM_56800V4 to EM_56800EF.

include/elf:
* common.h: Rename EM_56800V4 to EM_56800EF.

x86: Update X86_64_GOT_TYPE_P to cover more GOT relocations

Add R_X86_64_GOT32, R_X86_64_GOT64, R_X86_64_GOTPCREL64 and
R_X86_64_GOTPLT64 to X86_64_GOT_TYPE_P to cover more GOT relocations.

PR ld/28858
* elfxx-x86.h (X86_64_GOT_TYPE_P): Add R_X86_64_GOT32,
R_X86_64_GOT64, R_X86_64_GOTPCREL64 and R_X86_64_GOTPLT64.

Add new e_machine values.

include/elf:
* common.h: Add EM_U16_U8CORE, EM_TACHYUM, EM_56800V4.

testsuite: fix failure in gdb.threads/killed-outside.exp

Starting with commit

  commit 1da5d0e664e362857153af8682321a89ebafb7f6
  Date:   Tue Jan 4 08:02:24 2022 -0700

    Change how Python architecture and language are handled

we see a failure in gdb.threads/killed-outside.exp:

  ...
  Executing on target: kill -9 16622    (timeout = 300)
  builtin_spawn -ignore SIGHUP kill -9 16622
  continue
  Continuing.
  Couldn't get registers: No such process.
  (gdb) [Thread 0x7ffff77c2700 (LWP 16626) exited]

  Program terminated with signal SIGKILL, Killed.
  The program no longer exists.
  FAIL: gdb.threads/killed-outside.exp: prompt after first continue (timeout)

This is not a regression but a failure due to a change in GDB's
output.  Prior to the aforementioned commit, GDB has been printing the
"Couldn't get registers: No such process." message twice.  The second
one came from

  (top-gdb) bt
  #0  amd64_linux_nat_target::fetch_registers (this=0x555557f31440 <the_amd64_linux_nat_target>, regcache=0x555558805ce0, regnum=16) at /gdb-up/gdb/amd64-linux-nat.c:225
  #1  0x000055555640ac5f in target_ops::fetch_registers (this=0x555557d636d0 <the_thread_db_target>, arg0=0x555558805ce0, arg1=16) at /gdb-up/gdb/target-delegates.c:502
  #2  0x000055555641a647 in target_fetch_registers (regcache=0x555558805ce0, regno=16) at /gdb-up/gdb/target.c:3945
  #3  0x0000555556278e68 in regcache::raw_update (this=0x555558805ce0, regnum=16) at /gdb-up/gdb/regcache.c:587
  #4  0x0000555556278f14 in readable_regcache::raw_read (this=0x555558805ce0, regnum=16, buf=0x555558881950 "") at /gdb-up/gdb/regcache.c:601
  #5  0x00005555562792aa in readable_regcache::cooked_read (this=0x555558805ce0, regnum=16, buf=0x555558881950 "") at /gdb-up/gdb/regcache.c:690
  #6  0x000055555627965e in readable_regcache::cooked_read_value (this=0x555558805ce0, regnum=16) at /gdb-up/gdb/regcache.c:748
  #7  0x0000555556352a37 in sentinel_frame_prev_register (this_frame=0x555558181090, this_prologue_cache=0x5555581810a8, regnum=16) at /gdb-up/gdb/sentinel-frame.c:53
  #8  0x0000555555fa4773 in frame_unwind_register_value (next_frame=0x555558181090, regnum=16) at /gdb-up/gdb/frame.c:1235
  #9  0x0000555555fa420d in frame_register_unwind (next_frame=0x555558181090, regnum=16, optimizedp=0x7fffffffd570, unavailablep=0x7fffffffd574, lvalp=0x7fffffffd57c, addrp=0x7fffffffd580,
      realnump=0x7fffffffd578, bufferp=0x7fffffffd5b0 "") at /gdb-up/gdb/frame.c:1143
  #10 0x0000555555fa455f in frame_unwind_register (next_frame=0x555558181090, regnum=16, buf=0x7fffffffd5b0 "") at /gdb-up/gdb/frame.c:1199
  #11 0x00005555560178e2 in i386_unwind_pc (gdbarch=0x5555587c4a70, next_frame=0x555558181090) at /gdb-up/gdb/i386-tdep.c:1972
  #12 0x0000555555cd2b9d in gdbarch_unwind_pc (gdbarch=0x5555587c4a70, next_frame=0x555558181090) at /gdb-up/gdb/gdbarch.c:3007
  #13 0x0000555555fa3a5b in frame_unwind_pc (this_frame=0x555558181090) at /gdb-up/gdb/frame.c:948
  #14 0x0000555555fa7621 in get_frame_pc (frame=0x555558181160) at /gdb-up/gdb/frame.c:2572
  #15 0x0000555555fa7706 in get_frame_address_in_block (this_frame=0x555558181160) at /gdb-up/gdb/frame.c:2602
  #16 0x0000555555fa77d0 in get_frame_address_in_block_if_available (this_frame=0x555558181160, pc=0x7fffffffd708) at /gdb-up/gdb/frame.c:2665
  #17 0x0000555555fa5f8d in select_frame (fi=0x555558181160) at /gdb-up/gdb/frame.c:1890
  #18 0x0000555555fa5bab in lookup_selected_frame (a_frame_id=..., frame_level=-1) at /gdb-up/gdb/frame.c:1720
  #19 0x0000555555fa5e47 in get_selected_frame (message=0x0) at /gdb-up/gdb/frame.c:1810
  #20 0x0000555555cc9c6e in get_current_arch () at /gdb-up/gdb/arch-utils.c:848
  #21 0x000055555625b239 in gdbpy_before_prompt_hook (extlang=0x555557451f20 <extension_language_python>, current_gdb_prompt=0x555557f4d890 <top_prompt+16> "(gdb) ")
      at /gdb-up/gdb/python/python.c:1063
  #22 0x0000555555f7cfbb in ext_lang_before_prompt (current_gdb_prompt=0x555557f4d890 <top_prompt+16> "(gdb) ") at /gdb-up/gdb/extension.c:922
  #23 0x0000555555f7d442 in std::_Function_handler<void (char const*), void (*)(char const*)>::_M_invoke(std::_Any_data const&, char const*&&) (__functor=...,
      __args#0=@0x7fffffffd900: 0x555557f4d890 <top_prompt+16> "(gdb) ") at /usr/include/c++/7/bits/std_function.h:316
  #24 0x0000555555f752dd in std::function<void (char const*)>::operator()(char const*) const (this=0x55555817d838, __args#0=0x555557f4d890 <top_prompt+16> "(gdb) ")
      at /usr/include/c++/7/bits/std_function.h:706
  #25 0x0000555555f75100 in gdb::observers::observable<char const*>::notify (this=0x555557f49060 <gdb::observers::before_prompt>, args#0=0x555557f4d890 <top_prompt+16> "(gdb) ")
      at /gdb-up/gdb/../gdbsupport/observable.h:150
  #26 0x0000555555f736dc in top_level_prompt () at /gdb-up/gdb/event-top.c:444
  #27 0x0000555555f735ba in display_gdb_prompt (new_prompt=0x0) at /gdb-up/gdb/event-top.c:411
  #28 0x00005555564611a7 in tui_on_command_error () at /gdb-up/gdb/tui/tui-interp.c:205
  #29 0x0000555555c2173f in std::_Function_handler<void (), void (*)()>::_M_invoke(std::_Any_data const&) (__functor=...) at /usr/include/c++/7/bits/std_function.h:316
  #30 0x0000555555e10c20 in std::function<void ()>::operator()() const (this=0x5555580f9028) at /usr/include/c++/7/bits/std_function.h:706
  #31 0x0000555555e10973 in gdb::observers::observable<>::notify() const (this=0x555557f48d20 <gdb::observers::command_error>) at /gdb-up/gdb/../gdbsupport/observable.h:150
  #32 0x00005555560e9b3f in start_event_loop () at /gdb-up/gdb/main.c:438
  #33 0x00005555560e9bcc in captured_command_loop () at /gdb-up/gdb/main.c:481
  #34 0x00005555560eb616 in captured_main (data=0x7fffffffddd0) at /gdb-up/gdb/main.c:1348
  #35 0x00005555560eb67c in gdb_main (args=0x7fffffffddd0) at /gdb-up/gdb/main.c:1363
  #36 0x0000555555c1b6b3 in main (argc=12, argv=0x7fffffffded8) at /gdb-up/gdb/gdb.c:32

Commit 1da5d0e664 eliminated the call to 'get_current_arch'
in 'gdbpy_before_prompt_hook'.  Hence, the second instance of
"Couldn't get registers: No such process." does not appear anymore.

Fix the failure by updating the regular expression in the test.

PowerPC64 treatment of absolute symbols

Supporting -static-pie on PowerPC64 requires the linker to properly
treat SHN_ABS symbols for cases like glibc's _nl_current_LC_CTYPE_used
absolute symbol.  I've been slow to fix the linker on powerpc because
there is some chance that this will break some shared libraries or
PIEs.

bfd/
* elf64-ppc.c (ppc64_elf_check_relocs): Consolidate local sym
handling code.  Don't count dyn relocs against non-dynamic
absolute symbols.
(dec_dynrel_count): Adjust to suit.
(ppc64_elf_edit_toc): Don't remove entries for absolute symbols
when pic.
(allocate_got): Don't allocate space for got relocs against
non-dynamic absolute syms.
(ppc64_elf_layout_multitoc): Likewise.
(got_and_plt_relr): Likewise.
(ppc64_elf_size_dynamic_sections): Likewise for local got.
(got_and_plt_relr_for_local_syms): Likewise.
(ppc64_elf_size_stubs): Don't allocate space for relr either.
(ppc64_elf_relocate_section): Don't write relocs against non-dynamic
absolute symbols.  Don't optimise got and toc code sequences
loading absolute symbol entries.
ld/
* testsuite/ld-powerpc/abs-reloc.s,
* testsuite/ld-powerpc/abs-static.d,
* testsuite/ld-powerpc/abs-static.r,
* testsuite/ld-powerpc/abs-pie.d,
* testsuite/ld-powerpc/abs-pie.r,
* testsuite/ld-powerpc/abs-shared.d,
* testsuite/ld-powerpc/abs-shared.r,
* testsuite/ld-powerpc/abs-pie-relr.d,
* testsuite/ld-powerpc/abs-pie-relr.r,
* testsuite/ld-powerpc/abs-shared-relr.d,
* testsuite/ld-powerpc/abs-shared-relr.r: New tests.
* testsuite/ld-powerpc/powerpc.exp: Run them.

Automatic date update in version.in

Stop the BFD library complaining about compressed dwarf debug string sections being too big.

PR 28834
* dwarf2.c (read_section): Change the heuristic that checks for
overlarge dwarf debug info sections.

gdb: fix formatting for help set/show extended-prompt

The formatting of the help text for 'help set extended-prompt' and
'help show extended-prompt' is a little off.

Here's the offending snippet:

    Substitutions are applied to VALUE to compute the real prompt.

    The currently defined substitutions are:
      \[ Begins a sequence of non-printing characters.
  \\ A backslash.
  \] Ends a sequence of non-printing characters.
  \e The ESC character.

Notice that the line for '\[' is indented more that the others.

Turns out this is due to how we build this help text, something which
is done in Python.  We extended a classes __doc__ string with some
dynamically generated text.

The classes doc string looks like this:

    """Set the extended prompt.

    Usage: set extended-prompt VALUE

    Substitutions are applied to VALUE to compute the real prompt.

    The currently defined substitutions are:
    """

Notice the closing """ are in a line of their own, and include some
white space just before.  It's this extra white space that's causing
the problem.

Fix the formatting issue by moving the """ to the end of the previous
line.  I then add the extra newline in at the point where the doc
string is merged with the dynamically generated text.

Now everything lines up correctly.

gdb: test to check one aspect of the linespec parsing code

While working on the fix for PR cli/28665 (see previous couple of
commits), I was playing with making a change in the linespec parsing
code.  Specifically, I was thinking about whether the spec_string for
LINESPEC_LOCATION locations should ever be nullptr.

I made a change to prevent the spec_string from ever being nullptr,
tested gdb, and saw no regressions.

However, as part of this work I was reviewing how the breakpoint code
handles this case (spec_string being nullptr), and spotted that in
parse_breakpoint_sals the nullptr case is specifically handled, so
changing this should have caused a regression.  But I didn't see one.

So, this commit adds a comment in location.c mentioning that the
nullptr case is (a) not an oversight, and (b) is required.  Then I add
a new test to gdb.base/break.exp that ensures a change in this area
will cause a regression.

This test passes on current gdb, but with my modified (and broken)
gdb, the test would fail.

gdb: handle calls to edit command passing only a linespec condition

While working on the previous commit to fix PR cli/28665, I noticed
that the 'edit' command would suffer from the same problem.  That is,
something like:

  (gdb) edit task 123

would cause GDB to break.  For a full explanation of what's going on
here, see the commit message for the previous commit.

As with the previous commit, this issue can be prevented by detecting,
and throwing, a junk at the end of the line error earlier, before
calling decode_line_1.

So, that's what this commit does.  I've also added some tests for this
issue.

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

gdb: handle calls to list command passing only a linespec condition

In PR cli/28665, it was reported that GDB would crash when given a
command like:

  (gdb) list task 123

The problem here is that in cli/cli-cmd.c:list_command, the string
'task 123' is passed to string_to_event_location in find a location
specification.  However, this location parsing understands about
breakpoint conditions, and so, will stop parsing when it sees
something that looks like a condition, in this case, the 'task 123'
looks like a breakpoint condition.

As a result, the location we get back from string_to_event_location
has no actual location specification attached to it.  The actual call
path is:

  list_command
    string_to_event_location
      string_to_event_location_basic
        new_linespec_location

In new_linespec_location we call linespec_lex_to_end, which looks at
'task 123' and decides that there's nothing there that describes a
location.  As such, in new_linespec_location, the spec_string field of
the location is left as nullptr.

Back in list_command we then call decode_line_1, which calls
event_location_to_sals, which calls parse_linespec, which takes the
spec_string we found earlier, and tries to converts this into a list
of sals.

However, parse_linespec is not intended to be passed a nullptr, for
example, calling is_ada_operator will try to access through the
nullptr, causing undefined behaviour.  But there are other cases
within parse_linespec which don't expect to see a nullptr.

When looking at how to fix this issue, I first considered having
linespec_lex_to_end detect the problem.  That function understands
when the first thing in the linespec is a condition keyword, and so,
could throw an error saying something like: "no linespec before
condition keyword", however, this is not going to work, at least, not
without additional changes to GDB, it is valid to place a breakpoint
like:

  (gdb) break task 123

This will place a breakpoint at the current location with the
condition 'task 123', and changing linespec_lex_to_end breaks this
behaviour.

So, next, I considered what would happen if I added a condition to an
otherwise valid list command, this is what I see:

  (gdb) list file.c:1 task 123
  Junk at end of line specification.
  (gdb)

So, then I wondered, could we just pull the "Junk" detection forward,
so that we throw the error earlier, before we call decode_line_1?

It turns out that yes we can.  Well, sort of.

It is simpler, I think, to add a separate check into the list_command
function, after calling string_to_event_location, but before calling
decode_line_1.  We know when we call string_to_event_location that the
string in question is not empty, so, after calling
string_to_event_location, if non of the string has been consumed, then
the content of the string must be junk - it clearly doesn't look like
a location specification.

I've reused the same "Junk at end of line specification." error for
consistency, and added a few tests to cover this issue.

While the first version of this patch was on the mailing list, a
second bug PR gdb/28797 was raised.  This was for a very similar
issue, but this time the problem command was:

  (gdb) list ,,

Here the list command understands about the first comma, list can have
two arguments separated by a comma, and the first argument can be
missing.  So we end up trying to parse the second command "," as a
linespec.

However, in linespec_lex_to_end, we will stop parsing a linespec at a
comma, so, in the above case we end up with an empty linespec (between
the two commas), and, like above, this results in the spec_string
being nullptr.

As with the previous case, I've resolved this issue by adding an extra
check for junk at the end of the line - after parsing (or failing to
parse) the nothing between the two commas, we still have the "," left
at the end of the list command line - when we see this we can throw
the same "junk at the end of the line" error, and all is good.

I've added tests for this case too.

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

gdb/testsuite: move linespec test into gdb.linespec/ directory

The gdb.base/linespecs.exp test should really live in the gdb.linespec
directory, so lets move it there.

As we already have gdb.linespec/linespec.exp, I've renamed the test to
gdb.linespec/errors.exp, as this better reflects what the test is
actually checking.

Finally, the test script doesn't have its own source file, it was
reusing a random other source file, gdb.base/memattr.c.  Now the tests
script is in gdb.linespec/, I've updated the test to use a different
source file from that directory.

gdb: add empty string check in parse_linespec

If parse_linespec (linespec.c) is passed ARG as an empty string then
we end up calling `strchr (linespec_quote_characters, '\0')`, which
will return a pointer to the '\0' at the end of
linespec_quote_characters.  This then results in GDB calling
skip_quote_char with `ARG + 1`, which is undefined behaviour (as ARG
only contained a single character, the '\0').

Fix this by checking for the first character of ARG being '\0' before
the call to strchr.

I have additionally added an assertion that ARG can't itself be
nullptr, as calling is_ada_operator with nullptr can end up calling
'startswith' on the nullptr, which is undefined behaviour.

Finally, I moved the declaration of TOKEN into the body of
parse_linespec, to where TOKEN is defined.

This patch came about while I was working on fixes for PR cli/28665
and PR gdb/28797.  The actual fixes for these two issues will be in a
later commit in this series, but, with this patch in place, both of
the above bugs would hit the new assertion rather than accessing
invalid memory and crashing.  The '\0' check is not currently ever
hit, but just makes the code a little safer.

Because this patch only changes the nature of the failure for the
above two bugs, there's no tests here.  A later commit will fix the
above two issues, at which point I'll add some tests.

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

gdb: update the comment on string_to_event_location

The comment on string_to_event_location is (I believe) out of date.
This commit fixes the two issues I see:

  1. This function can't return NULL any more.  The implementation
  calls string_to_explicit_location which can return NULL, but if this
  is the case we then call string_to_event_location_basic, which I
  don't believe can ever return NULL.

  2. I've removed the mention that the returned string is malloc'd,
  though this is true, now that we return a managed pointer, I believe
  the source of the memory allocation is irrelevant, and so, shouldn't
  be discussed in the header comment.

There should be no user visible changes after this commit.

Updated French translation for the ld/ and gold/ sub-directories

or1k: Avoid R_OR1K_GOT16 signed overflow by using special howto

Previously when fixing PR 21464 we masked out upper bits of the
relocation value in order to avoid overflow complaints when acceptable.
It turns out this does not work when the relocation value ends up being
signed.

To fix this this patch introduces a special howto with
complain_on_overflow set to complain_overflow_dont.  This is used in
place of the normal R_OR1K_GOT16 howto when we detect R_OR1K_GOT_AHI16
relocations.

bfd/ChangeLog:

PR 28735
* elf32-or1k.c (or1k_elf_got16_no_overflow_howto): Define.
(or1k_elf_relocate_section): Use new howto instead of trying to
mask out relocation bits.

Automatic date update in version.in

Fix flex rule in gdb

Currently, if flex fails, it will leave the resulting .c file in the
tree.  This will cause a cascade of errors, and requires the manual
deletion of the .c file in order to recreate the problem.

It's better for the rule to fail such that the .c file is not updated.
This way, 'make' will fail the same way every time -- which is much
handier for debugging syntax errors.

This fix just updates the Makefile rule to follow the way that the
"yacc" rule already works.

gdb, btrace: improve error messages

When trying to use 'record btrace' on a system that does not support it,
the error message isn't as clear as it could be.  See
https://sourceware.org/pipermail/gdb/2022-January/049870.html.

Improve the error message in a few cases.

Reported-by: Simon Sobisch <simonsobisch@gnu.org>

gdb/python: fix gdb.Objfile.__repr__ () for dynamically compiled code

While experimenting with JIT reader API I realized that calling repr ()
on objfile created by JIT reader crashes GDB.

The problem was that objfpy_repr () called objfile_filename () which
returned NULL, causing PyString_FromFormat () to crash.

This commit fixes this problem by using objfile_name () instead of
objfile_filename (). This also makes consistent with the value of gdb.Objfile.filename variable.

hurd: Fix RPC prototypes

The last updates of MIG introduced qualifying strings and arrays with
const as appropriate.  We thus have to update the protypes in gdb too.

Change-Id: I3f72aac1dfa6e58d1394d5776b822d7c8f2409df

hurd: Fix RPC link names

The RPC stub code expects to be calling a C function, not a C++
function.

Change-Id: Idd7549fc118f2addc7fb4975667a011cacacc03f

Automatic date update in version.in

elf: Check symbol version without any symbols

VER_FLG_WEAK doesn't indicate that all symbol references of the symbol
version have STB_WEAK.  VER_FLG_WEAK indicates a weak symbol version
definition with no symbols associated with it.  It is used to verify
the existence of a particular implementation without any symbol references
to the weak symbol version.

PR ld/24718
* testsuite/ld-elf/pr24718-1.d: New file.
* testsuite/ld-elf/pr24718-1.s: Likewise.
* testsuite/ld-elf/pr24718-1.t: Likewise.

Load debug section only when dumping debug sections

Don't load debug sections if we aren't dumping any debug sections.

PR binutils/28843
* objdump.c (dump_any_debugging): New.
(load_debug_section): Return false if dump_any_debugging isn't
set.
(main): Set dump_any_debugging when dumping any debug sections.
* readelf (dump_any_debugging): New.
(parse_args): Set dump_any_debugging when dumping any debug
sections.
(load_debug_section): Return false if dump_any_debugging isn't
set.

gdb: fix some clang-tidy readability-misleading-indentation warnings

I have warnings like these showing in my editor all the time, so I
thought I'd run clang-tidy with this diagnostic on all the files (that I
can compile) and fix them.

There is still one warning, in utils.c, but that's because some code
is mixed up with preprocessor macros (#ifdef TUI), so I think there no
good solution there.

Change-Id: I345175fc7dd865318f0fbe61ac026c88c3b6a96b

gdb, testsuite, fortran: adapt info symbol expected output for intel compilers

Info symbol is expected to print the symbol table name of a symbol, since
symbol lookup happens via the minimal symbol table.  This name
corresponds to the linkage name in the full symbol table.

For gfortran (and maybe others) these names currently have the form
XXXX.NUMBER where XXXX is the symbol name and NUMBER a compiler
generated appendix for mangling.
An example taken from the modified nested-funcs-2.exp would be

~~~~
$ objdump -t ./outputs/gdb.fortran/nested-funcs-2/nested-funcs-2 | grep \
increment
00000000000014ab l  F .text  0000000000000095  increment.3883
000000000000141c l  F .text  000000000000008f  increment_program_global.3881
~~~~

This mangled name gets recognized by the Ada demangler/decoder and decoded as
Ada to XXXX (setting the symbol language to Ada).  This leads to output
of XXXX over XXXX.NUMBER for info symbol on gfortran symbols.

For ifort and ifx the generated linkage names have the form
SCOPEA_SCOPEB_XXXX_ which are not recognized by the Ada decoder (or any
other demangler for that matter) and thus printed as is.
The respective objdump in the above case looks like

~~~~
$ objdump -t ./outputs/gdb.fortran/nested-funcs-2/nested-funcs-2 | grep \
increment
0000000000403a44 l  F .text  0000000000000074  contains_keyword_IP_increment_
0000000000403ab8 l  F .text  0000000000000070
contains_keyword_IP_increment_program_global_
~~~~

In the unmodified testcase this results in 'fails' when ran with the intel
compilers:

~~~~
>> make check RUNTESTFLAGS="gdb.fortran/nested-funcs-2.exp \
GDBFLAGS='$GDBFLAGS' CC_FOR_TARGET='icpc' F90_FOR_TARGET='ifort'"

...

                === gdb Summary ===

\# of expected passes            80
\# of unexpected failures        14
~~~~

Note that there is no Fortran mangling standard.  We keep the gfortran
behavior as is and modify the test to reflect ifx and ifort mangled
names which fixes above fails.

Signed-off-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>

Import patch from mainline GCC to fix an infinite recusion in the Rust demangler.

PR 98886
PR 99935
* rust-demangle.c (struct rust_demangler): Add a recursion
counter.
(demangle_path): Increment/decrement the recursion counter upon
entry and exit.  Fail if the counter exceeds a fixed limit.
(demangle_type): Likewise.
(rust_demangle_callback): Initialise the recursion counter,
disabling if requested by the option flags.

Re: PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu

In trying to find a testcase for PR28827, I managed to hit a linker
error in bfd_set_section_contents with a .branch_lt input section
being too large for the output .branch_lt.

bfd/
PR 28827
* elf64-ppc.c (ppc64_elf_size_stubs): Set section size to
maxsize past STUB_SHRINK_ITER before laying out.  Remove now
unnecessary conditional setting of maxsize at start of loop.
ld/
* testsuite/ld-powerpc/pr28827-2.d,
* testsuite/ld-powerpc/pr28827-2.lnk,
* testsuite/ld-powerpc/pr28827-2.s: New test.
* testsuite/ld-powerpc/powerpc.exp: Run it.

Remove unused variables in fbsd-tdep.c files

i386-fbsd-tdep.c and amd64-fbsd-tdep.c failed to build on my x86-64
Fedora 34 machine, using the system gcc, after a recent patch.  These
two files now have unused variables, which provokes a warning in this
configuration.

I'm checking in this patch to remove the unused variables.

Automatic date update in version.in

Automatic date update in version.in

Re: PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu

The previous patch wasn't quite correct.  The size and padding depends
on offset used in the current iteration, and if we're fudging the
offset past STUB_SHRINK_ITER then we'd better use that offset.  We
can't have plt_stub_pad using stub_sec->size as the offset.

PR 28827
* elf64-ppc.c (plt_stub_pad): Add stub_off param.
(ppc_size_one_stub): Set up stub_offset to value used in this
iteration before sizing the stub.  Adjust plt_stub_pad calls.

objcopy --only-keep-debug

From: Peilin Ye <peilin.ye@bytedance.com>
objcopy's --only-keep-debug option has been broken for ELF files since
commit 8c803a2dd7d3.

  1. binutils/objcopy.c:setup_section() marks non-debug sections as
     SHT_NOBITS, then calls bfd_copy_private_section_data();
  2. If ISEC and OSEC share the same section flags,
     bfd/elf.c:_bfd_elf_init_private_section_data() restores OSEC's
     section type back to ISEC's section type, effectively undoing
     "make_nobits".

* objcopy.c (setup_section): Act on make_nobits after calling
bfd_copy_private_section_data.

Automatic date update in version.in

gdb: fix ppc-sysv-tdep.c build on 32-bit platforms

The previous code triggered the following error on an i386 host:

/git/gdb/gdb/ppc-sysv-tdep.c:1764:34: error: non-constant-expression cannot be narrowed from type 'ULONGEST' (aka 'unsigned long long') to 'size_t' (aka 'unsigned int') in initializer list [-Wc++11-narrowing]
              unscaled.read ({writebuf, TYPE_LENGTH (valtype)},
                                        ^~~~~~~~~~~~~~~~~~~~~
/git/gdb/gdb/gdbtypes.h:2043:31: note: expanded from macro 'TYPE_LENGTH'
                              ^~~~~~~~~~~~~~~~~~
/git/gdb/gdb/ppc-sysv-tdep.c:1764:34: note: insert an explicit cast to silence this issue
              unscaled.read ({writebuf, TYPE_LENGTH (valtype)},
                                        ^~~~~~~~~~~~~~~~~~~~~
                                        static_cast<size_t>( )
/git/gdb/gdb/gdbtypes.h:2043:31: note: expanded from macro 'TYPE_LENGTH'
                              ^~~~~~~~~~~~~~~~~~
1 error generated.

Fix this by using gdb::make_array_view.

FreeBSD x86 nat: Use register maps for GP register sets.

Rather than using the x86-specific register offset tables, use
register maps to describe the layout of the general purpose registers
fetched via PT_GETREGS.  The sole user-visible difference is that
FreeBSD/amd64 will now report additional segment registers ($ds, $es,
$fs, and $gs) for both 32-bit and 64-bit processes.

As part of these changes, the FreeBSD x86 native targets no longer use
amd64-bsd-nat.c or i386-bsd-nat.c.  Remove FreeBSD-specific register
handling (for $fs_base, $gs_base, and XSAVE state) from these files.
Similarly, remove the global x86bsd_xsave_len from x86-bsd-nat.c.  The
FreeBSD x86 native targets use a static xsave_len instead.

While here, rework the probing of PT_GETXMMREGS on FreeBSD/i386.
Probe the ptrace op once in the target read_description method and
cache the result for the future similar to the way the status of XSAVE
support is probed in the read_description method.  In addition, return
the proper xcr0 mask (X87-only) for old kernels or systems without
either XSAVE or XMM support.

fbsd-nat: Return a bool from fetch_register_set and store_register_set.

Change these helper functions to return true if they did any work.

FreeBSD x86: Use tramp-frame for signal frames.

Use a register map to describe the registers in mcontext_t as part of
the signal frame as is done on several other FreeBSD arches.  This
permits fetching the fsbase and gsbase register values from the signal
frame for both amd64 and i386 and permits fetching additional segment
registers stored as 16-bit values on amd64.

While signal frames on FreeBSD do contain floating point/XSAVE state,
these unwinders do not attempt to supply those registers.  The
existing x86 signal frame uwinders do not support these registers, and
the only existing functions which handle FSAVE/FXSAVE/XSAVE state all
work with regcaches.  In the future these unwinders could create a
tempory regcache, collect floating point registers, and then supply
values out of the regcache into the trad-frame.

Use register maps for gp regsets on FreeBSD/x86 core dumps.

In particular, this permits reporting the value of the $ds, $es, $fs,
and $gs segment registers from amd64 core dumps since they are stored
as 16-bit values rather than the 32-bit size assumed by i386_gregset.

regcache: Zero-extend small registers described by a register map.

When registers are supplied via regcache_supply_register from a
register block described by a register map, registers may be stored in
slots smaller than GDB's native register size (e.g. x86 segment
registers are 16 bits, but the GDB registers for those are 32-bits).
regcache_collect_regset is careful to zero-extend slots larger than a
register size, but regcache_supply_regset just used
regcache::raw_supply_part and did not initialize the upper bytes of a
register value.

trad_frame_set_reg_regmap assumes these semantics (zero-extending
short registers).  Upcoming patches also require these semantics for
handling x86 segment register values stored in 16-bit slots on
FreeBSD.  Note that architecturally x86 segment registers are 16 bits,
but the x86 gdb architectures treat these registers as 32 bits.

FreeBSD x86: Remove fallback for detecting signal trampolines by address.

A few FreeBSD releases did not include the page holding the signal
code in core dumps.  As a workaround, a sysctl was used to fetch the
default location of the signal code instead.  The youngest affected
FreeBSD release is 10.1 released in November 2014 and EOLed in
December 2016.  The fallback only works for native processes and would
require a separate unwinder once the FreeBSD arches are converted to
use tramp_frame for signal frames.

Remove support for pre-5.0 FreeBSD/i386 signal trampolines.

The last relevant release (FreeBSD 4.11) was released in January of
2005.

Remove vestigal FreeBSD/i386 3.x support.

This was orphaned when a.out support was removed as the FreeBSD/i386
ELF support always used the register layouts from 4.0+.

Add Bruno Larsen to gdb/MAINTAINERS

gdb/build: Fix Wpessimizing-move in clang build

When building with clang, I run into an error:

...
tui/tui-disasm.c:138:25: error: moving a temporary object prevents copy
elision [-Werror,-Wpessimizing-move]
      tal.addr_string = std::move (gdb_dis_out.release ());
                        ^
tui/tui-disasm.c:138:25: note: remove std::move call here
      tal.addr_string = std::move (gdb_dis_out.release ());
                        ^~~~~~~~~~~                      ~
...

The error above is caused by the recent commit 5d10a2041eb8 ("gdb: add
string_file::release method").

Fix this by removing std::move.

Build on x86_64-linux with clang 13.0.0.

Add top-level .editorconfig file

Add a .editorconfig [1] file.  This helps configure editors
automatically with the right whitespace settings.  It will help me,
since I need to juggle with different whitespace settings for different
projects.   But I think it can also help newcomers get things right from
the start.

Some editors have native support for reading these files, while others
require a plug-in [2].  And if you don't want to use it, then this file
doesn't change anything to your life.

I added rules for the kinds of files I edit most often, but more can be
added later.  I assumed that the rules were the same for GDB and the
other projects, but if that's not the case, we can always put
.editorconfig files in project subdirectories to override settings.

[1] https://editorconfig.org/
[2] https://editorconfig.org/#download

Change-Id: Ifda136d13877fafcf0d137fec8501f6a34e1367b

Updated French translation for the gas sub-directory.

Set __ehdr_start rel_from_abs earlier

This is just a tidy, making the __ehdr_start symbol flag tweaks all in
one place.

* ldelf.c (ldelf_before_allocation): Don't set rel_from_abs
for __ehdr_start.
* ldlang.c (lang_symbol_tweaks): Set it here instead.

PowerPC64 handling of @tocbase

* elf64-ppc.c (ppc64_elf_relocate_section): Warn if the symbol
on R_PPC64_TOC isn't local.

Update PowerPC64 symtocbase test

Using a symbol other than .TOC. with @tocbase is an extension to the
ABI.  It is never valid to use a symbol without a definition in the
binary, and symbols on these expressions cannot be overridden.  Make
this explicit by using ".hidden" in the testcase.

* testsuite/ld-powerpc/symtocbase-1.s: Align data.  Make function
entry symbol hidden.
* testsuite/ld-powerpc/symtocbase-2.s: Likewise.
* testsuite/ld-powerpc/symtocbase.d: Adjust expected output.

PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu

The assertion is this one in ppc_build_one_stub
  BFD_ASSERT (stub_entry->stub_offset >= stub_entry->group->stub_sec->size);
It is checking that a stub doesn't overwrite the tail of a previous
stub, so not something trivial.

Normally, stub sizing iterates until no stubs are added, detected by
no change in stub section size.  Iteration also continues if no stubs
are added but one or more stubs increases in size, which also can be
detected by a change in stub section size.  But there is a
pathological case where stub section sizing decreases one iteration
then increases the next.  To handle that situation, stub sizing also
stops at more than STUB_SHRINK_ITER (20) iterations when calculated
stub section size is smaller.  The previous larger size is kept for
the actual layout (so that building the stubs, which behaves like
another iteration of stub sizing, will see the stub section sizes
shrink).  The problem with that stopping condition is that it assumes
that stub sizing is only affected by addresses external to the stub
sections, which isn't always true.

This patch fixes that by also keeping larger individual stub_offset
addresses past STUB_SHRINK_ITER.  It also catches a further
pathological case where one stub shrinks and another expands in such a
way that no stub section size change is seen.

PR 28827
* elf64-ppc.c (struct ppc_link_hash_table): Add stub_changed.
(STUB_SHRINK_ITER): Move earlier in file.
(ppc_size_one_stub): Detect any change in stub_offset.  Keep
larger one if past STUB_SHRINK_ITER.
(ppc64_elf_size_stubs): Iterate on stub_changed too.

PR28826 x86_64 ld segfaults building xen

Fallout from commit e86fc4a5bc37

PR 28826
* coffgen.c (coff_write_alien_symbol): Init dummy to zeros.

PR28753, buffer overflow in read_section_stabs_debugging_info

PR 28753
* rddbg.c (read_section_stabs_debugging_info): Don't read past
end of section when concatentating stab strings.

Automatic date update in version.in

gdb: work around negative DW_AT_data_member_location GCC 11 bug

g++ 11.1.0 has a bug where it will emit a negative
DW_AT_data_member_location in some cases:

    $ cat test.cpp
    #include <memory>

    int
    main()
    {
      std::unique_ptr<int> ptr;
    }
    $ g++ -g test.cpp
    $ llvm-dwarfdump -F a.out
    ...
    0x00000964:       DW_TAG_member
                        DW_AT_name [DW_FORM_strp]   ("_M_head_impl")
                        DW_AT_decl_file [DW_FORM_data1]     ("/usr/include/c++/11.1.0/tuple")
                        DW_AT_decl_line [DW_FORM_data1]     (125)
                        DW_AT_decl_column [DW_FORM_data1]   (0x27)
                        DW_AT_type [DW_FORM_ref4]   (0x0000067a "default_delete<int>")
                        DW_AT_data_member_location [DW_FORM_sdata]  (-1)
    ...

This leads to a GDB crash (when built with ASan, otherwise probably
garbage results), since it tries to read just before (to the left, in
ASan speak) of the value's buffer:

    ==888645==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000c52af at pc 0x7f711b239f4b bp 0x7fff356bd470 sp 0x7fff356bcc18
    READ of size 1 at 0x6020000c52af thread T0
        #0 0x7f711b239f4a in __interceptor_memcpy /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827
        #1 0x555c4977efa1 in value_contents_copy_raw /home/simark/src/binutils-gdb/gdb/value.c:1347
        #2 0x555c497909cd in value_primitive_field(value*, long, int, type*) /home/simark/src/binutils-gdb/gdb/value.c:3126
        #3 0x555c478f2eaa in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:333
        #4 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
        #5 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
        #6 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
        #7 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
        #8 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
        #9 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
        #10 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
        #11 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
        #12 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
        #13 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
        #14 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
        #15 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
        #16 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
        #17 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
        #18 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
        #19 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
        #20 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
        #21 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
        #22 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
        #23 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
        #24 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
        #25 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
        #26 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
        #27 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
        #28 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
        #29 0x555c4760f04c in c_value_print(value*, ui_file*, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:587
        #30 0x555c483ff954 in language_defn::value_print(value*, ui_file*, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:614
        #31 0x555c49759f61 in value_print(value*, ui_file*, value_print_options const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1189
        #32 0x555c48950f70 in print_formatted /home/simark/src/binutils-gdb/gdb/printcmd.c:337
        #33 0x555c48958eda in print_value(value*, value_print_options const&) /home/simark/src/binutils-gdb/gdb/printcmd.c:1258
        #34 0x555c48959891 in print_command_1 /home/simark/src/binutils-gdb/gdb/printcmd.c:1367
        #35 0x555c4895a3df in print_command /home/simark/src/binutils-gdb/gdb/printcmd.c:1458
        #36 0x555c4767f974 in do_simple_func /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:97
        #37 0x555c47692e25 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2475
        #38 0x555c4936107e in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:670
        #39 0x555c485f1bff in catch_command_errors /home/simark/src/binutils-gdb/gdb/main.c:523
        #40 0x555c485f249c in execute_cmdargs /home/simark/src/binutils-gdb/gdb/main.c:618
        #41 0x555c485f6677 in captured_main_1 /home/simark/src/binutils-gdb/gdb/main.c:1317
        #42 0x555c485f6c83 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1338
        #43 0x555c485f6d65 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1363
        #44 0x555c46e41ba8 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
        #45 0x7f71198bcb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
        #46 0x555c46e4197d in _start (/home/simark/build/binutils-gdb-one-target/gdb/gdb+0x77f197d)

    0x6020000c52af is located 1 bytes to the left of 8-byte region [0x6020000c52b0,0x6020000c52b8)
    allocated by thread T0 here:
        #0 0x7f711b2b7459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
        #1 0x555c470acdc9 in xcalloc /home/simark/src/binutils-gdb/gdb/alloc.c:100
        #2 0x555c49b775cd in xzalloc(unsigned long) /home/simark/src/binutils-gdb/gdbsupport/common-utils.cc:29
        #3 0x555c4977bdeb in allocate_value_contents /home/simark/src/binutils-gdb/gdb/value.c:1029
        #4 0x555c4977be25 in allocate_value(type*) /home/simark/src/binutils-gdb/gdb/value.c:1040
        #5 0x555c4979030d in value_primitive_field(value*, long, int, type*) /home/simark/src/binutils-gdb/gdb/value.c:3092
        #6 0x555c478f6280 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:501
        #7 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
        #8 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
        #9 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
        #10 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
        #11 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
        #12 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
        #13 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
        #14 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
        #15 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
        #16 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
        #17 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
        #18 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
        #19 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
        #20 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
        #21 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
        #22 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
        #23 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
        #24 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
        #25 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
        #26 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
        #27 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
        #28 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
        #29 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048

Since there are some binaries with this in the wild, I think it would be
useful for GDB to work around this.  I did the obvious simple thing, if
the DW_AT_data_member_location's value is -1, replace it with 0.  I
added a producer check to only apply this fixup for GCC 11.  The idea is
that if some other compiler ever uses a DW_AT_data_member_location value
of -1 by mistake, we don't know (before analyzing the bug at least) if
they did mean 0 or some other value.  So I wouldn't want to apply the
fixup in that case.

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

Fix GDB internal error by using text (instead of data) section offset

Fedora Rawhide is now using gcc-12.0.  As part of updating to the
gcc-12.0 package set, Rawhide is also now using a version of libgcc_s
which lacks a .data section.  This causes gdb to fail in the following
fashion while debugging a program (such as gdb) which uses libgcc_s:

    (top-gdb) run
    Starting program: rawhide-master/bld/gdb/gdb
    ...
    objfiles.h:467: internal-error: sect_index_data not initialized
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    ...

I snipped the backtrace from the above output.  Instead, here's a
portion of a backtrace obtained using GDB's backtrace command.
(Obviously, in order to obtain it, I used a GDB which has been patched
with this commit.)

    #0  internal_error (
file=0xc6a508 "gdb/objfiles.h", line=467,
fmt=0xc6a4e8 "sect_index_data not initialized")
at gdbsupport/errors.cc:51
    #1  0x00000000005f9651 in objfile::data_section_offset (this=0x4fa48f0)
at gdb/objfiles.h:467
    #2  0x000000000097c5f8 in relocate_address (address=0x17244, objfile=0x4fa48f0)
at gdb/stap-probe.c:1333
    #3  0x000000000097c630 in stap_probe::get_relocated_address (this=0xa1a17a0,
objfile=0x4fa48f0)
at gdb/stap-probe.c:1341
    #4  0x00000000004d7025 in create_exception_master_breakpoint_probe (
objfile=0x4fa48f0)
at gdb/breakpoint.c:3505
    #5  0x00000000004d7426 in create_exception_master_breakpoint ()
at gdb/breakpoint.c:3575
    #6  0x00000000004efcc1 in breakpoint_re_set ()
at gdb/breakpoint.c:13407
    #7  0x0000000000956998 in solib_add (pattern=0x0, from_tty=0, readsyms=1)
at gdb/solib.c:1001
    #8  0x00000000009576a8 in handle_solib_event ()
at gdb/solib.c:1269
    ...

The function 'relocate_address' in gdb/stap-probe.c attempts to do
its "relocation" by using objfile->data_section_offset().  That
method, data_section_offset() is defined as follows in objfiles.h:

  CORE_ADDR data_section_offset () const
  {
    return section_offsets[SECT_OFF_DATA (this)];
  }

The internal error occurs when the SECT_OFF_DATA macro finds that the
'sect_index_data' field is -1:

    #define SECT_OFF_DATA(objfile) \
 ((objfile->sect_index_data == -1) \
  ? (internal_error (__FILE__, __LINE__, \
     _("sect_index_data not initialized")), -1) \
  : objfile->sect_index_data)

relocate_address() is obtaining the section offset in order to compute
a relocated address.  For some ABIs, such as the System V ABI, the
section offsets will all be the same.  So for those ABIs, it doesn't
matter which offset is used.  However, other ABIs, such as the FDPIC
ABI, will have different offsets for the various sections.  Thus, for
those ABIs, it is vital that this and other relocation code use the
correct offset.

In stap_probe::get_relocated_address, the address to which to add the
offset (thus forming the relocated address) is obtained via
this->get_address (); get_address is a getter for m_address in
probe.h.  It's documented/defined as follows (also in probe.h):

  /* The address where the probe is inserted, relative to
     SECT_OFF_TEXT.  */
  CORE_ADDR m_address;

(Thanks to Tom Tromey for this observation.)

So, based on this, the current use of data_section_offset /
SECT_OFF_DATA is wrong.  This relocation code should have been using
text_section_offset / SECT_OFF_TEXT all along.  That being the
case, I've adjusted the stap-probe.c relocation code accordingly.

Searching the sources turned up one other use of data_section_offset,
in gdb/dtrace-probe.c, so I've updated that code as well.  The same
reasoning presented above applies to this case too.

Summary:

* gdb/dtrace-probe.c (dtrace_probe::get_relocated_address):
Use method text_section_offset instead of data_section_offset.
* gdb/stap-probe.c (relocate_address): Likewise.

gdb, remote, btrace: move switch_to_thread call right before xfer call

In remote_target::remote_btrace_maybe_reopen, we switch to the currently
iterated thread in order to set inferior_ptid for a subsequent xfer.

Move the switch_to_thread call directly before the target_read_stralloc
call to clarify why we need to switch threads.

gdb, gdbserver: update thread identifier in enable_btrace target method

The enable_btrace target method takes a ptid_t to identify the thread on
which tracing shall be enabled.

Change this to thread_info * to avoid translating back and forth between
the two.  This will be used in a subsequent patch.

gdb, btrace: switch threads in remote_btrace_maybe_reopen()

In remote_btrace_maybe_reopen() we iterate over threads and use
set_general_thread() to set the thread from which to transfer the btrace
configuration.

This sets the remote general thread but does not affect inferior_ptid.  On
the xfer request later on, remote_target::xfer_partial() again sets the
remote general thread to inferior_ptid, overwriting what
remote_btrace_maybe_reopen() had done.

In one case, this led to inferior_ptid being null_ptid when we tried to
enable tracing on a newly created thread inside a newly created process
during attach.

This, in turn, led to find_inferior_pid() asserting when we iterated over
threads in record_btrace_is_replaying(), which was called from
record_btrace_target::xfer_partial() when reading the btrace configuration
of the new thread to check whether it was already being recorded.

The bug was exposed by

    0618ae41497 gdb: optimize all_matching_threads_iterator

and found by

    FAIL: gdb.btrace/enable-new-thread.exp: ... (GDB internal error)

Use switch_to_thread() in remote_btrace_maybe_reopen().