packaging: add binutils-libs dependency in build

Fix configure error

/usr/lib64/gcc/x86_64-tizen-linux-gnu/13.1.0/../../../../x86_64-tizen-linux-gnu/bin/as:
error while loading shared libraries: libbfd-2.40.so: cannot open shared
object file: No such file or directory

Change-Id: I85267dabad3b190333dba377671f17f8137837d1
Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>

packaging: add libs package with GPL-2.0+ licensed

Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>

packaging: Remove libsframe.la with docs

Change-Id: I97cc889e768f8755627075117a23884f4e0313e6
Signed-off-by: Slava Barinov <v.barinov@samsung.com>

Remove gas/doc/.dirstamp failing the build

Change-Id: I29920dceb4c168339cff63c6784e092808d407cc
Signed-off-by: Slava Barinov <v.barinov@samsung.com>

Do not change the timestamp when updating the gas asconfig file.

 PR 28909 * doc/local.mk (asconfig.texi): Use "cp -p" to preserve timestamps. * Makefile.in: Regenerate.

packaging: Bump version to 2.40

Change-Id: I0ed6c5efe6da862c633c55197f5b49994b36f648
Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>

readline: fix path in configure.in

The path fix allows configure dumper to collect the information.

Change-Id: I347977a90df5fcaed59e37f1701ef32ae96d85ee
Signed-off-by: Slava Barinov <v.barinov@samsung.com>

packaging: fix build error

error: Installed (but unpackaged) file(s) found:
    /usr/lib64/libctf-nobfd.la
    /usr/lib64/libctf.la

Change-Id: I78ab9706a099a4fccb2d66508a4d529c7882d74e
Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>

packaging: Fix build breaks and packaging after upgrade to 2.39

Remove two additional directories related to gdb.

Package new shared libraries and remove libtool files.

Change-Id: I8deeb28b0a7a0ed9a51dea7d17ba4541d6415586
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>

Revert "Ignore broken plugins"

This reverts commit c5efd9444c2c43dc0e1f3e8ac1129a34ea13c579.

packaging: fix error

[  211s]     Installed (but unpackaged) file(s) found:
[  211s]    /usr/lib64/libbfd.la
[  211s]    /usr/lib64/libopcodes.la

Change-Id: I1beca706e75ae1afd869d3aac04537b02c6f5123
Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>

packaging: keep shared libraries for libbfd & libopcodes

Change-Id: I48e2d9bea9fb68fd7ab2c5d766f906ce385f645b
Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>

packaging: disable binutils_run_tests of cross binutils

Cross-toolchain testing is not straightforward.

Change-Id: I4670e694b4e26cf4d94786cb6c3824b9cb42cacd
Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>

packaging: Turn off separate-code for i586

Change-Id: Id1126e73b8bbe641f3c80fc84b016bfa5df10571
Signed-off-by: Slava Barinov <v.barinov@samsung.com>

Fix error while linking Tizen Apps

cherry-picked from RS-TizenStudio/gcc-9.2/pull/10

Change-Id: I30e8222f838680785c22527ab9295bb9c2f9e902
Signed-off-by: Karthik Bhat <kv.bhat@samsung.com>
Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>

packaging: Add support for configure-dumper

Change-Id: Icb766cf48e675d30a5843355679be786b6e531b7
Signed-off-by: Slava Barinov <v.barinov@samsung.com>

packaging: Enable testing infrastructrure

Now Binutils can be tested just like GCC package, by defining run_tests to 1

Change-Id: I10a8667985ee3cd430ea8fbdbbd06653a4d72df8
Signed-off-by: Slava Barinov <v.barinov@samsung.com>

configure: diabled relro by default

Change-Id: I74fa9ab77b0bb1a4a9a9a461235d929d985bd4e7
Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>

packaging: version bump

Change-Id: Id27d126ac3d940e72645de8f3e6b0f81c10c04c5
Signed-off-by: Slava Barinov <v.barinov@samsung.com>

ld/testing: clear compiler & linker flags when running testsuite.

Passing CLFAGS, CXXFLAGS, LDFLAGS used previously on build stage cause failures
when running "make check". It's safer to clear them.

Change-Id: If2bba2baca0f99c3931af2a55739ff6a087f2b0f
Signed-off-by: Andrey Drobyshev <a.drobyshev@partner.samsung.com>

packaging: fix testsuite build.

 * Add list of dependent packages needed to build & run tests along with
corresponding macro run_tests;
 * Add %check section.

Signed-off-by: Andrey Drobyshev <a.drobyshev@partner.samsung.com>
Change-Id: I2cc277d6855247747025a4d3b744a5c7804f4fca

Add armv7hl support.

Change-Id: I1abc28bf90731946353b86579e85bd391c1745d3

Introduce --enable-new-dtags configure option.

ld/configure --enable-new-dtags sets ld.bfd --enable-new-dtags option by
default.

The ld option switches on generation of DT_RUNPATH tag instead of DT_RPATH tag
which is deprecated and breaks LD_LIBRARY_PATH usage.

Debian binutils bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835859

        * ld/configure.ac: Add --enable-new-dtags option.
        * ld/ldmain.c: Set link_info.new_dtags to 1 if when --enable-new-dtags is
          switched on.
        * ld/configure: Regenerate.
        * ld/config.in: Regenerate.
        * packaging/binutils.spec: Switch on --enable-new-dtags.
        * packaging/binutils-armv7l.spec: Regenerate.
        * packaging/binutils-aarch64.spec: Regenerate.

Change-Id: I0ec86f61a8b97d55c29bb441a9ae4db94060ea22
Signed-off-by: Slava Barinov <v.barinov@samsung.com>

2.27 version

Ignore broken plugins

Allow cross-configured ld to ignore plugins that cannot be dlopened

Change-Id: I0bbca32123aeba869d843fdfb9179815af888f5c
Signed-off-by: Yury Usishchev <y.usishchev@samsung.com>

Packaging added.

Signed-off-by: Slava Barinov <v.barinov@samsung.com>

Fix snafu in version number.  Regenerate files

Set development and experimental to false.  Update version number to 2.40.  Add release markers.  Regenerate files

Automatic date update in version.in

Updated Romainian translation for the bfd sub-directory

Automatic date update in version.in

ARM: Fix ld bloat introduced between binutils-2.38 and 2.39

Since commit 9833b7757d24, "PR28824, relro security issues",
ELF_MAXPAGESIZE matters much more, with regards to layout of
the linked file.  That commit fixed an actual bug, but also
exposes a problem for targets were that value is too high.

For example, for ARM(32, a.k.a. "Aarch32") specifically
bfd_arch_arm, it's set to 64 KiB, making all Linux(/GNU)
targets pay an extra amount of up to 60 KiB of bloat in
DSO:s and executables.  This matters when there are many
such files, and where storage is expensive.

It's *mostly* bloat when using a Linux kernel, as ARM(32) is
a good example of an target where ELF_MAXPAGESIZE is set to
an extreme value for an obscure corner-case.  The ARM
(32-bit) kernel has 4 KiB pages, has had that value forever,
and can't be configured to any other value.  The use-case is
IIUC "Aarch32" emulation on an "Aarch64" (arm64) kernel, but
not just that, but a setup where the Linux page-size is
configured to something other than the *default* 4 KiB.  Not
sure there actually any such systems in use, again with
both Aarch32 compatibility support and a non-4KiB pagesize,
with all the warnings in the kernel config and requiring the
"EXPERT" level set on.

So, let's do like x86-64 in a2267dbfc9e1 "x86-64: Use only
one default max-page-size" and set ELF_MAXPAGESIZE to 4096.

bfd:
* elf32-arm.c (ELF_MAXPAGESIZE): Always set to 0x1000.
(cherry picked from commit 1a26a53a0dee39106ba58fcb15496c5f13074652)

ld/testsuite: Adjust for ELF_MAXPAGESIZE 0x1000

Many tests reflect a setting of ELF_MAXPAGESIZE to 64 KiB.
With ELF_MAXPAGESIZE changed to 4 KiB, layout is sometimes
different and symbols end up in other places.  Avoid churn
and regexpification of old test patterns by passing the
max-page-size setting active at the time.

ld/testsuite:

* testsuite/ld-arm/arm-elf.exp,
        testsuite/ld-arm/non-contiguous-arm2.d,
        testsuite/ld-arm/non-contiguous-arm3.d,
        testsuite/ld-arm/non-contiguous-arm5.d,
        testsuite/ld-arm/non-contiguous-arm6.d,
        testsuite/ld-arm/thumb-plt-got.d, testsuite/ld-arm/thumb-plt.d:
Pass -z max-page-size=0x10000 explicitly to test that rely on
that value in output-matching patterns.
(cherry picked from commit b305015577bb92d3041e55a72ca8cd43f7c05748)

libctf: ctf-link outdated input check faulty

This check has a pair of faults which, combined, can lead to memory
corruption.  Firstly, it assumes that the values of the ctf_link_inputs
hash are ctf_dict_t's: they are not, they are ctf_link_input_t's, a much
shorter structure.  So the flags check which is the core of this is
faulty (but happens, by chance, to give the right output on most
architectures, since usually we happen to get a 0 here, so the test that
checks this usually passes).  Worse, the warning that is emitted when
the test fails is added to the wrong dict -- it's added to the input
dict, whose warning list is never consumed, rendering the whole check
useless.  But the dict it adds to is still the wrong type, so we end up
overwriting something deep in memory (or, much more likely,
dereferencing a garbage pointer and crashing).

Fixing both reveals another problem: the link input is an *archive*
consisting of multiple members, so we have to consider whether to check
all of them for the outdated-func-info thing we are checking here.
However, no compiler exists that emits a mixture of members with this
flag on and members with it off, and the linker always reserializes (and
upgrades) such things when it sees them: so all members in a given
archive must have the same value of the flag, so we only need to check
one member per input archive.

libctf/
PR libctf/29983
* ctf-link.c (ctf_link_warn_outdated_inputs): Get the types of
        members of ctf_link_inputs right, fixing a possible spurious
        tesst failure / wild pointer deref / overwrite.  Emit the
        warning message into the right dict.

Ensure that libbacktrace/allocfail.sh is not deleted when creating release tarballs.

* Makefile.am (CLEANFILES): Import patch from upstream to prevent
allocafail.sh from being removed when running 'make clean'.

Automatic date update in version.in

Fix a potential illegal memory access in the BFD library when parsing a corrupt DWARF file.

PR 29988
* dwarf2.c (read_indexed_address): Fix check for an out of range
offset.

gas/RISC-V: adjust assembler for opcode table re-ordering

PR gas/29940

With the single-operand JAL entry now sitting ahead of the two-operand
one, the parsing of a two-operand insn would first try to parse an 'a'-
style operand, resulting in the insertion of bogus (and otherwise
unused) undefined symbols in the symbol table, having register names.
Since 'a' is used as 1st operand only with J and JAL, and since JAL is
the only insn _also_ allowing for a register as 1st operand (and then
there being a 2nd one), special case this parsing aspect right there.

Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>

Automatic date update in version.in

IBM zSystems: Fix offset relative to static TLS

For local exec TLS relocations of the form foo@NTPOFF+x the addend was
ignored.

bfd/ChangeLog:

* elf32-s390.c (elf_s390_relocate_section): Honor addend for
R_390_TLS_LE32.
* elf64-s390.c (elf_s390_relocate_section): Honor addend for
R_390_TLS_LE64.

ld/ChangeLog:

* testsuite/ld-s390/reloctlsle-1.d: New test.
* testsuite/ld-s390/reloctlsle-1.s: New test.

(cherry picked from commit aefebe82dc89711384b85329daa48d04c1d3a45b)

Automatic date update in version.in

sframe: fix the defined SFRAME_FRE_TYPE_*_LIMIT constants

An earlier commit 3f107464 defined the SFRAME_FRE_TYPE_*_LIMIT
constants.  These constants are used (by gas and libsframe) to pick an
SFrame FRE type based on the function size.  Those constants, however,
were buggy, causing the generated SFrame sections to be bloated as
SFRAME_FRE_TYPE_ADDR2/SFRAME_FRE_TYPE_ADDR4 got chosen more often than
necessary.

gas/
* sframe-opt.c (sframe_estimate_size_before_relax): Use
typecast.
(sframe_convert_frag): Likewise.

libsframe/
* sframe.c (sframe_calc_fre_type): Use a more appropriate type
for argument.  Adjust the check for SFRAME_FRE_TYPE_ADDR4_LIMIT
to keep it warning-free but meaningful.

include/
* sframe-api.h (sframe_calc_fre_type): Use a more appropriate
type for the argument.
* sframe.h (SFRAME_FRE_TYPE_ADDR1_LIMIT): Correct the constant.
(SFRAME_FRE_TYPE_ADDR2_LIMIT): Likewise.
(SFRAME_FRE_TYPE_ADDR4_LIMIT): Likewise.

(cherry picked from commit 725a19bfd142c845bf76ae28f6289972fd1cf5db)

libsframe: adjust an incorrect check in flip_sframe

When sframe_encoder_write needs to flip the buffer containing the SFrame
section before writing, it is not necessary that the SFrame FDES are in
the order of their sfde_func_start_fre_off.  On the contrary, SFrame
FDEs will be sorted in the order of their start address.  So, remove
this incorrect assumption which is basically assuming that the last
sfde_func_start_fre_off seen will help determine the end of the flipped
buffer.

The function now keeps track of the bytes_flipped and then compares it with
the expected value.  Also, added two more checks at appropriate places:
 - check that the SFrame FDE read is within bounds
 - check that the SFrame FRE read is within bounds

libsframe/

* sframe.c (flip_sframe): Adjust an incorrect check.
Add other checks to ensure reads are within the buffer size.

(cherry picked from commit cd9aea32cffd8089f6f63f4eb86d4dccfc0b3850)

Skip ld/pr23169 test on arm.

The test is already skipped on several targets (including AArch64)
because it's invalid.

* testsuite/ld-ifunc/ifunc.exp: Skip pr23169 on arm.

Fix PR18841 ifunc relocation ordering

In order to get the ifunc relocs properly sorted the correct class
needs to be returned.  The code mimics what has been done for AArch64.

Fixes:
FAIL: Run pr18841 with libpr18841b.so
FAIL: Run pr18841 with libpr18841c.so
FAIL: Run pr18841 with libpr18841bn.so (-z now)
FAIL: Run pr18841 with libpr18841cn.so (-z now)

bfd/
PR ld/18841
* elf32-arm.c (elf32_arm_reloc_type_class): Return
reloc_class_ifunc for ifunc symbols.

ld/testsuite/
* ld-arm/ifunc-12.rd: Update relocations order.
* ld-arm/ifunc-3.rd: Likewise.
* ld-arm/ifunc-4.rd: Likewise.

Updated transaltions for the gprof and binutils sub-directories

Automatic date update in version.in

PR29972, inconsistent format specification in singular form

PR 29972
* readelf.c (process_dynamic_section): Correct format string.

(cherry picked from commit 02da71ee20ec71f7b3be85cf2266e09c124983bf)

Automatic date update in version.in

Automatic date update in version.in

ld: yet another PDB build fix (or workaround)

Older bash looks to improperly deal with backslashes in here-documents,
leaving them in place on the escaped double quotes inside the parameter
expansion. Convert to a model without using such a construct, by simply
splitting the here-documents into three ones.

Updated Bulgarian and Russian translations for LD and BFD respectively

Automatic date update in version.in

Avoid unaligned pointer reads in PEP idata section

Updated Bulgarian and Russian translations for the gprof subdirectory

Automatic date update in version.in

Merge config/picflag.m4 from gcc

Update some more copyright year ranges

These files disappear in commit 3002e78a7d3d but are still on the branch.

Update year range in gprofng copyright notices

This adds 'Innovative Computing Labs' as an external author to
update-copyright.py, to cover the copyright notice in
gprofng/common/opteron_pcbe.c, and uses that plus another external
author 'Oracle and' to update gprofng copyright dates.  I'm not going
to commit 'Oracle and' as an accepted author, but that covers the
string "Copyright (c) 2006, 2012, Oracle and/or its affiliates. All
rights reserved." found in gprofng/testsuite/gprofng.display/jsynprog
files.

Update year range in copyright notice of binutils files

The newer update-copyright.py fixes file encoding too, removing cr/lf
on binutils/bfdtest2.c and ld/testsuite/ld-cygwin/exe-export.exp, and
embedded cr in binutils/testsuite/binutils-all/ar.exp string match.

Update etc/update-copyright.py

This picks up some improvements from gcc/contrib.  exceptions must
derive from BaseException, port to python3, retain original file mode,
fix name of script in examples.

Adds libsframe to list of default dirs.  I would have added gprofng
too but there are some files claiming copyright by authors other than
the Free Software Foundation.

Fix AArch64 linker testsuite failures triggered by differences in build environments.

PR 29843
* testsuite/ld-aarch64/bti-plt-5.d: Relax regxps slightly to allow
for differences in build environments.
* testsuite/ld-aarch64/tls-relax-gdesc-le-now.d: Likewise.

Avoid unaligned pointer reads in PEP .idata section

This is something I discovered when working on aarch64, though it's
relevant to x86_64 too.

The PE32+ imports are located in the .idata section, which starts off
with a 20-byte structure for each DLL, containing offsets into the rest
of the section. This is the Import Directory Table in
https://learn.microsoft.com/en-us/windows/win32/debug/pe-format, which
is a concatenation of the .idata$2 sections. This is then followed by an
20 zero bytes generated by the linker script, which calls this .idata$3.

After this comes the .idata$4 entries for each function, which the
loader overwrites with the function pointers. Because there's no padding
between .idata$3 and .idata$4, this means that if there's an even number
of DLLs, the function pointers won't be aligned on an 8-byte boundary.

Misaligned reads are slower on x86_64, but this is more important on
aarch64, as the e.g. `ldr x0, [x0, :lo12:__imp__func]` the compiler
might generate requires __imp__func (the .idata$4 entry) to be aligned
to 8 bytes. Without this you get IMAGE_REL_ARM64_PAGEOFFSET_12L overflow
errors.

Automatic date update in version.in

Updated translations for various languages and sub-directories

Automatic date update in version.in

Automatic date update in version.in

Update version number and regenerate files

Add markers for 2.40 branch

sync libiberty sources with gcc mainline

[gdb/cli] Add maintenance ignore-probes

There's a command "disable probes", but SystemTap probes, for instance
libc:longjmp cannot be disabled:
...
$ gdb -q -batch a.out -ex start -ex "disable probes libc ^longjmp$"
  ...
Probe libc:longjmp cannot be disabled.
Probe libc:longjmp cannot be disabled.
Probe libc:longjmp cannot be disabled.
...

Add a command "maintenance ignore-probes" that ignores probes during
get_probes, such that we can easily pretend to use a libc without the
libc:longjmp probe:
...
(gdb) maint ignore-probes -verbose libc ^longjmp$
ignore-probes filter has been set to:
PROVIDER: 'libc'
PROBE_NAME: '^longjmp$'
OBJNAME: ''
(gdb) start ^M
  ...
Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M
...

The "Ignoring ..." messages can be suppressed by not using -verbose.

Note that as with "disable probes", running simply "maint ignore-probes"
ignores all probes.

The ignore-probes filter can be reset by using:
...
(gdb) maint ignore-probes -reset
ignore-probes filter has been reset
...

For now, the command is only supported for SystemTap probes.

PR cli/27159
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27159

ld/testsuite: Don't add index to sizes in pdb.exp

ld: Handle LF_VFTABLE types in PDBs

ld: Handle extended-length data structures in PDB types

A few fixes to minor issues I've discovered in my PDB patches.

* If sizes or offsets are greater than 0x8000, they get encoded as
extended values in the same way as for enum values - e.g. a LF_ULONG
.short followed by a .long.

* I've managed to coax MSVC to produce another type, LF_VFTABLE, which
is seen when dealing with COM. I don't think LLVM emits this. Note that
we can't just implement everything in Microsoft's header files, as most
of it is obsolete.

* Fixes a stupid bug in the test program, where I was adding an index to
a size. The index was hard-coded to 0, so this didn't cause any actual
issues.

Updated Romanian translation for the binutils sub-directory

[gdb/python] Fix gdb.python/py-finish-breakpoint2.exp for -m32

[ Partial resubmission of an earlier submission by Andrew (
https://sourceware.org/pipermail/gdb-patches/2012-September/096347.html ), so
listing him as co-author. ]

With x86_64-linux and target board unix/-m32, we have:
...
(gdb) continue^M
Continuing.^M
Exception #10^M
^M
Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M
23        throw new int (e);^M
(gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \
  check FinishBreakpoint in catch()
...

The following scenario happens:
- set breakpoint in throw_exception_1, a function that throws an exception
- continue
- hit breakpoint, with call stack main.c:38 -> throw_exception_1
- set a finish breakpoint
- continue
- hit the breakpoint again, with call stack main.c:48 -> throw_exception
  -> throw_exception_1

Due to the exception, the function call did not properly terminate, and the
finish breakpoint didn't trigger.  This is expected behaviour.

However, the intention is that gdb detects this situation at the next stop
and calls the out_of_scope callback, which would result here in this test-case
in a rather confusing "exception did not finish" message.  So the problem is
that this message doesn't show up, in other words, the out_of_scope callback
is not called.

[ Note that the fact that the situation is detected only at the next stop
(wherever that happens to be) could be improved upon, and the earlier
submission did that by setting a longjmp breakpoint.  But I'm considering this
problem out-of-scope for this patch. ]

Note that the message does show up later, at thread exit:
...
[Inferior 1 (process 20046) exited with code 0236]^M
exception did not finish ...^M
...

The decision on whether to call the out_of_scope call back is taken in
bpfinishpy_detect_out_scope_cb, and the interesting bit is here:
...
             if (b->pspace == current_inferior ()->pspace
                 && (!target_has_registers ()
                     || frame_find_by_id (b->frame_id) == NULL))
               bpfinishpy_out_of_scope (finish_bp);
...

In the case of the thread exit, the callback triggers because
target_has_registers () == 0.

So why doesn't the callback trigger in the case of the breakpoint?

Well, the b->frame_id is the frame_id of the frame of main (the frame
in which the finish breakpoint is supposed to trigger), so AFAIU
frame_find_by_id (b->frame_id) == NULL will only be true once we've
left main, at which point I guess we don't stop till thread exit.

Fix this by saving the frame in which the finish breakpoint was created, and
using frame_find_by_id () == NULL on that frame instead, such that we have:
...
(gdb) continue^M
Continuing.^M
Exception #10^M
^M
Breakpoint 3, throw_exception_1 (e=10) at py-finish-breakpoint2.cc:23^M
23        throw new int (e);^M
exception did not finish ...^M
(gdb) FAIL: gdb.python/py-finish-breakpoint2.exp: \
  check FinishBreakpoint in catch()
...

Still, the test-case is failing because it's setup to match the behaviour that
we get on x86_64-linux with target board unix/-m64:
...
(gdb) continue^M
Continuing.^M
Exception #10^M
stopped at ExceptionFinishBreakpoint^M
(gdb) PASS: gdb.python/py-finish-breakpoint2.exp: \
  check FinishBreakpoint in catch()
...

So what happens here?  Again, due to the exception, the function call did not
properly terminate, but the finish breakpoint still triggers.  This is somewhat
unexpected.  This happens because it just so happens to be that the frame
return address at which the breakpoint is set, is also the first instruction
after the exception has been handled.  This is a know problem, filed as
PR29909, so KFAIL it, and modify the test-case to expect the out_of_scope
callback.

Also add a breakpoint after setting the finish breakpoint but before throwing
the exception, to check that we don't call the out_of_scope callback too early.

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

Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
PR python/27247
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27247

[gdb/testsuite] Fix gdb.base/print-symbol-loading.exp on ubuntu 22.04.1

On ubuntu 22.04.1 x86_64, I run into:
...
(gdb) PASS: gdb.base/print-symbol-loading.exp: shlib off: \
  set print symbol-loading off
sharedlibrary .*^M
Symbols already loaded for /lib/x86_64-linux-gnu/libc.so.6^M
Symbols already loaded for /lib/x86_64-linux-gnu/libpthread.so.0^M
(gdb) FAIL: gdb.base/print-symbol-loading.exp: shlib off: load shared-lib
...

The test-case expects the libc.so line, but not the libpthread.so line.

However, we have:
...
$ ldd /lib/x86_64-linux-gnu/libc.so.6
linux-vdso.so.1 (0x00007ffd7f7e7000)
libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (0x00007f4468c00000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4469193000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4468f3e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4468f39000)
...
so it's not unexpected that libpthread.so is loaded if libc.so is loaded.

Fix this by accepting the libpthread.so line.

Tested on x86_64-linux.

PR testsuite/29919
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29919

[gdb/testsuite] Replace deprecated pthread_yield in gdb.threads/watchpoint-fork.exp

On Ubuntu 22.04.1 x86_64, with glibc 2.35 I run into:
...
watchpoint-fork-mt.c: In function 'start':^M
watchpoint-fork-mt.c:67:7: warning: 'pthread_yield' is deprecated: \
  pthread_yield is deprecated, use sched_yield instead \
  [-Wdeprecated-declarations]^M
   67 |       i = pthread_yield ();^M
      |       ^^M
...

Fix this as suggested, by using sched_yield instead.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/corefile.exp with glibc 2.35

On Ubuntu 22.04.1 x86_64 (with glibc 2.35), I run into:
...
(gdb) PASS: gdb.base/corefile.exp: $_exitcode is void
bt^M
 #0  __pthread_kill_implementation (...) at ./nptl/pthread_kill.c:44^M
 #1  __pthread_kill_internal (...) at ./nptl/pthread_kill.c:78^M
 #2  __GI___pthread_kill (...) at ./nptl/pthread_kill.c:89^M
 #3  0x00007f4985e1a476 in __GI_raise (...) at ../sysdeps/posix/raise.c:26^M
 #4  0x00007f4985e007f3 in __GI_abort () at ./stdlib/abort.c:79^M
 #5  0x0000556b4ea4b504 in func2 () at gdb.base/coremaker.c:153^M
 #6  0x0000556b4ea4b516 in func1 () at gdb.base/coremaker.c:159^M
 #7  0x0000556b4ea4b578 in main (...) at gdb.base/coremaker.c:171^M
(gdb) PASS: gdb.base/corefile.exp: backtrace
up^M
 #1  __pthread_kill_internal (...) at ./nptl/pthread_kill.c:78^M
 78      in ./nptl/pthread_kill.c^M
(gdb) FAIL: gdb.base/corefile.exp: up
...

The problem is that the regexp used here:
...
gdb_test "up" "#\[0-9\]* *\[0-9xa-fH'\]* in .* \\(.*\\).*" "up"
...
does not fit the __pthread_kill_internal line which lacks the instruction
address due to inlining.

Fix this by making the regexp less strict.

Tested on x86_64-linux.

Automatic date update in version.in

[gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc

On ubuntu 22.04.1 x86_64, I run into:
...
(gdb) info probes all rtld rtld_map_complete^M
No probes matched.^M
(gdb) XFAIL: gdb.threads/dlopen-libpthread.exp: info probes all rtld rtld_map_complete
UNTESTED: gdb.threads/dlopen-libpthread.exp: no matching probes
...
This has been filed as PR testsuite/17016.

The problem is that the name rtld_map_complete is used, which was only
available in Fedora 17, and upstream the name map_complete was used.

In the email thread discussing a proposed patch (
https://sourceware.org/legacy-ml/gdb-patches/2014-09/msg00712.html ) it was
suggested to make the test-case handle both names.

So, handle both names: map_complete and rtld_map_complete.

This exposes the following FAIL:
...
(gdb) info sharedlibrary^M
From To    Syms Read Shared Object Library^M
$hex $hex  Yes       /lib64/ld-linux-x86-64.so.2^M
$hex $hex  Yes (*)   /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0^M
$hex $hex  Yes       /lib/x86_64-linux-gnu/libc.so.6^M
$hex $hex  Yes       /lib/x86_64-linux-gnu/libdl.so.2^M
$hex $hex  Yes       /lib/x86_64-linux-gnu/libpthread.so.0^M
(*): Shared library is missing debugging information.^M
(gdb) FAIL: gdb.threads/dlopen-libpthread.exp: libpthread.so not found
...
due to using a glibc (v2.35) that has libpthread integrated into libc.

Fix this by changing the FAIL into UNSUPPORTED.

Tested on x86_64-linux.

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

[gdb/testsuite] Fix gdb.reverse/step-indirect-call-thunk.exp with -fcf-protection

On Ubuntu 22.04.1 x86_64, I run into:
...
gdb.reverse/step-indirect-call-thunk.c: In function 'inc':^M
gdb.reverse/step-indirect-call-thunk.c:22:1: error: '-mindirect-branch' and \
  '-fcf-protection' are not compatible^M
   22 | {                /* inc.1 */^M
      | ^^M
...

Fix this by forcing -fcf-protection=none, if supported.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.cp/step-and-next-inline.exp with -fcf-protection

On Ubuntu 22.04.1 x86_64, I run into:
...
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: not in inline 1
next^M
51        if (t != NULL^M
(gdb) FAIL: gdb.cp/step-and-next-inline.exp: no_header: next step 1
...

This is due to -fcf-protection, which adds the endbr64 at the start of get_alias_set:
...
0000000000001180 <_Z13get_alias_setP4tree>:
    1180:       f3 0f 1e fa             endbr64
    1184:       48 85 ff                test   %rdi,%rdi
...
so the extra insn gets an is-stmt line number entry:
...
INDEX  LINE   ADDRESS            IS-STMT PROLOGUE-END
  ...
11     50     0x0000000000001180 Y
12     50     0x0000000000001180
13     51     0x0000000000001184 Y
14     54     0x0000000000001184
...
and when stepping into get_alias_set we step to line 50:
...
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: in main
step^M
get_alias_set (t=t@entry=0x555555558018 <xx>) at step-and-next-inline.cc:50^M
50      {^M
...

In contrast, with -fcf-protection=none, we get:
...
0000000000001170 <_Z13get_alias_setP4tree>:
    1170:       48 85 ff                test   %rdi,%rdi
...
and:
...
INDEX  LINE   ADDRESS            IS-STMT PROLOGUE-END
  ...
11     50     0x0000000000001170 Y
12     51     0x0000000000001170 Y
13     54     0x0000000000001170
...
so when stepping into get_alias_set we step to line 51:
...
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: in main
step^M
get_alias_set (t=t@entry=0x555555558018 <xx>) at step-and-next-inline.cc:51^M
51        if (t != NULL^M
...

Fix this by rewriting the gdb_test issuing the step command to check which
line the step lands on, and issuing an extra next if needed.

Tested on x86_64-linux, both with and without -fcf-protection=none.

PR testsuite/29920
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29920

[gdb/symtab] Make comp_unit_head.length private

Make comp_unit_head.length private, to enforce using accessor functions.

Replace accessor function get_length with get_length_with_initial and
get_length_without_initial, to make it explicit which variant we're using.

Tested on x86_64-linux.

PR symtab/29343
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29343

PR29948, heap-buffer-overflow in display_debug_lines_decoded

This fixes a couple of places in display_debug_lines_decoded that were
off by one in checking DWARF5 .debug_line directory indices.  It also
displays the DWARF5 entry 0 for the program current directory rather
than "." as is done for pre-DWARF5.  I decided against displaying
DW_AT_comp_dir for pre-DWARF5 since I figure it is better for readelf
to minimally interpret debug info.

binutils/
PR 29948
* dwarf.c (display_debug_lines_decoded): Display the given
directory entry 0 for DWARF5.  Properly check directory index
against number of entries in the table.  Revert to using
unsigned int for n_directories and associated variables.
Correct warning messages.
gas/
* testsuite/gas/elf/dwarf-5-loc0.d: Update.

Automatic date update in version.in

RISC-V: Simplify riscv_csr_address logic on state enable extensions

This commit makes CSR class handling for 'Smstateen' and 'Ssstateen'
extensions simpler using fall-throughs (as used in CSR_CLASS_I{,_32}).

gas/ChangeLog:

* config/tc-riscv.c (riscv_csr_address): Simplify the logic for
'Smstateen' and 'Ssstateen' extensions.

Automatic date update in version.in

Use $decimal in timestamp.exp

This patch fixes a review comment by Tom de Vries.  He pointed out
that the new timestamp.exp should use the $decimal convenience regexp.

Fix "set debug timestamp"

PR cli/29945 points out that "set debug timestamp 1" stopped working
-- this is a regression due to commit b8043d27 ("Remove a ui-related
memory leak").

This patch fixes the bug and adds a regression test.

I think this should probably be backported to the gdb 13 branch.

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

Automatic date update in version.in

x86-64: Allocate input section memory if needed

When --no-keep-memory is used, the input section memory may not be cached.
Allocate input section memory for -z pack-relative-relocs if needed.

bfd/

PR ld/29939
* elfxx-x86.c (elf_x86_size_or_finish_relative_reloc): Allocate
input section memory if needed.

ld/

PR ld/29939
* testsuite/ld-elf/dt-relr-2i.d: New test.

RISC-V: Fix T-Head Fmv vendor extension encoding

A recent change in the XTheadFmv spec fixed an encoding bug in the
document. This patch changes the code to follow this bugfix.

Spec patch can be found here:
  https://github.com/T-head-Semi/thead-extension-spec/pull/11

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

Handle SIGSEGV in gdb selftests

The gdb.gdb self-tests were timing out for me, which turned out to be
PR testsuite/29325.  Looking into it, the problem is that the version
of the Boehm GC that is used by Guile on my machine causes a SEGV
during stack probing.  This unexpected stop confuses the tests and
causes repeated timeouts.

This patch adapts the two failing tests.  This makes them work for me,
and reduces the running time of gdb.gdb from 20 minutes to about 11
seconds.

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

sim: build: clean up unused codegen logic

Now that all igen ports are in the top-level makefile, we don't need
this logic in any subdirs anymore, so clean it up.

sim: mips: hoist "multi" igen rules up to common builds

Since these are the last mips igen rules, we can clean up a number of
bits in the local Makefile.in.

sim: mips: hoist "m16" igen rules up to common builds

sim: mips: hoist "single" igen rules up to common builds

sim: mips: rename "igen" generation mode to "single"

The naming in here has grown organically and is confusing to follow.
Originally there was only one set of rules for generating code from
the igen sources, so calling it "tmp-igen" and such made sense.  But
when other multigen modes were added ("m16" & "multi") which also
used igen, it's not clear what's common igen and what's specific to
this generation  mode.  So rename the set of rules from "igen" to
"single" so it's easier to follow.

sim: mips: hoist itable igen rules up to common builds

Since this rule is pretty simple, hoist it up to the common build.