Jan Beulich [Fri, 14 Feb 2025 08:33:18 +0000 (09:33 +0100)]
gas: fix rs_fill_nop listing
In commit a0094f1a70e1 ("gas: make .nops output visible in listing") I
was wrongly assuming fr_fix would be zero for rs_fill_nop, when that's
only a side effect of listing_newline() inserting dummy frags, but only
when file/line did actually change from the previous invocation. This is
in particular not going to be true when the .nops directive isn't the
first statement on a line.
Alan Modra [Sun, 26 Jan 2025 02:42:45 +0000 (13:12 +1030)]
loongson buffer overflow
bfd_elfNN_loongarch_set_data_segment_info can be called from the target
after_allocation function with a non-ELF hash table. This is seen in
the ld-elf pr21884 testcase. Fix the problem by first checking the
hash table type before writing to a loongarch_elf_hash_table field.
Richard Earnshaw [Thu, 23 Jan 2025 10:53:54 +0000 (10:53 +0000)]
aarch64: Fix PLT fixups when BTI is used [PR32572]
PR ld/32572
There are two problems addressed in this PR. Firstly, the choice of
whether or not a PLT stub needs a BTI on entry was too strict,
resulting in non-pie executables not having a BTI on their stub. But
secondly, the logic to handle each stub types did not agree across the
various places where this information is used.
The first issue is fixed by using bfd_link_executable rather than
bfd_link_pde. The second is addressed by recording a delta for PLT
stub alongside the stub itself. This is then used without needing
additional logic later on since it has been pre-calculated.
A more comprehensive fix would involve creating a data structure to
describe each fixup, including a call-back function to apply any
relocations. But that's a fairly large change and not appropriate for
backporting.
ld: fix alignment issue for ARM thumb long branch stub using PureCode section
When pure-code option is activated. The linker creates for M-profile architecures
a 2-bytes branch instruction. This causes the section alignment to be set to 2-byte
alignment instead of 4-byte alignment. This is a problem for long branch stub
without pure-code section as it contains a 32-bit address as data, which is expected
to be 4-byte aligned. Hence creating a long branch stub for PureCode section followed
by a long branch stub will result in a misalignment for the 32-bit address.
An easy fix is to add a nop instruction after the branch to keep the section alignment
to 4 bytes.
There is still a problem building the bfd docs from a release tar
file.
As the release tar file contains the pre-generated .texi files we
expect the bfd/doc build stage to symlink to the pre-existing .texi
files in the source tree.
However, this is still not working as expected if $(srcdir) is
relative. The problem is this line in REGEN_TEXI:
test -e $$texi || test ! -f $(srcdir)/$$texi || $(LN_S) $(srcdir)/$$texi $$texi; \
This is executed from the build/bfd/ directory, so if $(srcdir) is
relative, then this will get you from the bfd/ directory in the build
tree to the corresponding bfd/ directory in the src tree. However,
the symlink is created in the bfd/doc/ build directory. The relative
path will then fail to take you to the bfd/ directory in the src
tree.
Fix this by using $(abs_srcdir) when creating the symlink.
Jan Beulich [Wed, 22 Jan 2025 08:51:23 +0000 (09:51 +0100)]
x86/Solaris: correct support for Sun form of CMOV<size>.S
PR gas/32579
The deprecated .s (swapped operand encoding) functionality got in the
way of properly recognizing this specific form. Move the Solaris-
specific code ahead of that.
Alan Modra [Sat, 18 Jan 2025 12:09:05 +0000 (22:39 +1030)]
Support broken gcc test for gas string merge support
On casual reading of older gcc configure scripts it might be supposed
that the test for gas string merge support tries with %progbits after
a fail on ARM with @progbits. It doesn't succeed due to a bug. So to
support building of older gcc's for ARM without users having to edit
gcc sources, add a hack to gas. The hack can disappear in a few years
when building older gcc's likely requires other work too.
I've changed the docs to reflect what we actually allow for .section
syntax prior to this patch. (No way should this hack be documented as
allowed!)
PR 32491
* config/obj-elf.c (obj_elf_section): Allow missing entsize
for ARM gcc configure bug.
* doc/as.texi: Correct syntax of ELF .section directive.
* testsuite/gas/elf/string.s,
* testsuite/gas/elf/string.d: Test it.
Alan Modra [Sat, 18 Jan 2025 11:51:03 +0000 (22:21 +1030)]
run_dump_test warning/error regexp
This allows you to specify a run_dump_test warning that may or may not
be present using
warning: (warning_text_goes_here)?
ie. the regexp matches an empty string.
Richard Earnshaw [Fri, 17 Jan 2025 15:03:47 +0000 (15:03 +0000)]
gas: elf: Relax rules for SHF_STRING sections
Commit af3394d97a8c5187085c0eec5fb03e8da88db5fb allowed sections
declared with "S" (SHF_STRING) to specify the entity size, but then
would warn if the entity size was omitted, as with the old syntax.
Unfortunately, since specifying the entity size is incompatible with
binutils 2.43 or earlier, this makes it impossible to specify a
strings section in source code without generating an assembly warning
(the new syntax isn't supported in older assemblers and the old syntax
generates warnings).
Nevertheless, the old code was wrong in that it did not set the entity
size at all, in contravention of the ELF specification (though to date
there are no known cases where this mattered outside of mergeable
sections).
Fix this by permitting the original syntax without a warning again,
but by defaulting the entity size to 1. This is compatible with the
most common case of strings being byte-based.
Added some tests for the various flavours of declaration that we
support.
Alan Modra [Sat, 18 Jan 2025 00:25:22 +0000 (10:55 +1030)]
Re: binary outsymbols
The "of course to free outsymbols" turned out to be wrong. outsymbols
belongs to objcopy which frees them, so commit 6ca01b0bdd59 introduced
a double free.
Tom Tromey [Fri, 17 Jan 2025 19:01:38 +0000 (12:01 -0700)]
Simplify get_frame_unwind_table
This simplifies get_frame_unwind_table, changing it to use the
registry 'emplace' method and to pass the initialization iterators to
the constructor. This fixes a build problem on x86 -- reported by the
auto-builder -- as a side effect.
Tom de Vries reported that some of the test for the vmov[u|a]p[s|d] were
failing. In my machine xmm3 was consistently set to 0x54, but apparently
that is different depending on the system. This commit zeroes out xmm3
at the start of the test instead.
While debugging the test failures, I also noticed an issue where the
recording wasn't saving all the required memory. That happened because
vmovs[s|d] shares its opcode with vmovap[s|d], meaning they seem to
share code paths, but the latter encodes memory modification size on
VEX.L whereas the former encodes in VEX.pp. So this commit fixed that,
and made the relevant tests more robust and complete.
Andrew Burgess [Sat, 12 Oct 2024 10:08:04 +0000 (11:08 +0100)]
gdb/doc: some more details in the README file
After some recent discussions on the mailing list, I've made some
changes to the README to (I hope) provide more clarity.
The changes I made are:
1. Removed the use of a lone 'HOST' on the configure line. I tried
this and 'configure' gave me a warning:
configure: WARNING: you should use --build, --host, --target
So I don't think this is approved practice any more. We should
encourage users to use `--host` instead.
2. Added and reworded the --host, --target, and --enable-targets
descriptions in the 'configure options' section. My goals here are
to clarify that 'cross-debugging' is really the same as 'remote
debugging', and also to make it clearer what the defaults are.
3. Added some additional text to the 'Remote debugging' section
mentioning that 'remote debugging' is basically the same as 'cross
debugging', given that we use 'cross-debugging' in the text above.
gdb: add gdbarch method to get execution context from core file
The above commit improves GDB's ability to display inferior arguments
when opening a core file, however, if an argument includes white
space, then this is not displayed as well as it should be. For
example:
(gdb) core-file /tmp/corefile-exec-context.2.core
[New LWP 4069711]
Reading symbols from /tmp/corefile-exec-context...
Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e e e e e'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 return ret;
(gdb) show args
Argument list to give program being debugged when it is started is "aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e".
(gdb)
Notice the 'Core was generated by ...' line. In this case it is not
clear if the "e e e e e" is a single argument containing white space,
or 5 single arguments.
But when we 'show args' it is immediately clear that this is a single
argument, as the white space is now escaped.
This problem was caused by the above commit building the argument
string itself, and failing to consider white space escaping.
This commit changes things around, first we place the arguments into
the inferior, then, to print the 'Core was generated by ...' line, we
ask the inferior for the argument string. In this way the quoting is
handled just as it is for 'show args'. The initial output is now:
(gdb) core-file /tmp/corefile-exec-context.2.core
[New LWP 4069711]
Reading symbols from /tmp/corefile-exec-context...
Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f4f007af625 in raise () from /lib64/libc.so.6
(gdb)
Much better. The existing test is extended to cover this case.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Andrew Carlotti [Thu, 16 Jan 2025 02:34:44 +0000 (02:34 +0000)]
aarch64: Fix sve2p1 gating and add missing instructions
Many FEAT_SVE2p1 instructions need to be enabled by either of two
different features (one for streaming mode, and one for non-streaming
mode). This patch adds correct gating conditions for these
instructions.
There were also a few sve2p1 instructions missing altogether, so add
those as well.
The testsuite is modified to check for all alternative enablement
conditions. In many cases this is done by adding an alternative
assembler commands to existing test files. For some SME/SME2 tests,
only some of the instructions are enabled by +sve2p1, so these are
copied into a separate test. For original SVE2p1 tests, the non-SME2p1
instructions have been moved to a separate test file.
There are also new tests for the newly added instructions. These
include a couple of fixme comments relating to bad error reporting,
which should be investigated later.
Tom Tromey [Wed, 15 Jan 2025 23:18:15 +0000 (16:18 -0700)]
Remove mapped_index_base
The base class mapped_index_base is no longer needed. Previously it
was used by both the .gdb_index and .debug_names readers, but the
latter now uses the cooked index instead.
This patch removes mapped_index_base, merging it into
mapped_gdb_index. Supporting code that is specific to .gdb_index is
also moved into read-gdb-index.c. This shrinks dwarf2/read.c a bit,
which is nice.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32504 Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom Tromey [Thu, 16 Jan 2025 12:56:04 +0000 (05:56 -0700)]
Add missing includes of extract-store-integer.h
I found a number of .c files that need to include
extract-store-integer.h but that were only including it indirectly.
This patch adds the missing includes. This change enables the next
patch.
Guinevere Larsen [Thu, 14 Mar 2024 15:14:29 +0000 (16:14 +0100)]
gdb/testsuite: Test for a backtrace through object without debuginfo
Fedora has been carrying this test since back in the Project Archer
days. A change back then caused GDB to stop being able to backtrace when
only some of the object files had debug information. Even though the
changed code never seems to have made its way into the main GDB project,
I think it makes sense to bring the test along to ensure something like
this doesn't pass unnoticed.
Co-Authored-By: Jan Kratochvil <jan@jankratochvil.net> Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
Guinevere Larsen [Thu, 14 Mar 2024 15:14:28 +0000 (16:14 +0100)]
gdb: introduce ability to disable frame unwinders
Sometimes, in the GDB testsuite, we want to test the ability of specific
unwinders to handle some piece of code. Usually this is done by trying
to outsmart GDB, or by coercing the compiler to remove information that
GDB would rely on. Both approaches have problems as GDB gets smarter
with time, and that compilers might differ in version and behavior, or
simply introduce new useful information. This was requested back in 2003
in PR backtrace/8434.
To improve our ability to thoroughly test GDB, this patch introduces a
new maintenance command that allows a user to disable some unwinders,
based on either the name of the unwinder or on its class. With this
change, it will now be possible for GDB to not find any frame unwinders
for a given frame, which would previously cause GDB to assert. GDB will
now check if any frame unwinder has been disabled, and if some has, it
will just error out instead of asserting.
Unwinders can be disabled or re-enabled in 3 different ways:
* Disabling/enabling all at once (using '-all').
* By specifying an unwinder class to be disabled (option '-class').
* By specifying the name of an unwinder (option '-name').
If you give no options to the command, GDB assumes the input is an
unwinder class. '-class' would make no difference if used, is just here
for completeness.
This command is meant to be used once the inferior is already at the
desired location for the test. An example session would be:
(gdb) start
Temporary breakpoint 1, main () at omp.c:17
17 func();
(gdb) maint frame-unwinder disable ARCH
(gdb) bt
\#0 main () at omp.c:17
(gdb) maint frame-unwinder enable ARCH
(gdb) cont
Continuing.
This commit is a more generic version of commit 3c3bb0580be0,
and so, based on the final paragraph of the commit message:
gdb: Add switch to disable DWARF stack unwinders
<...>
If in the future we find ourselves adding more switches to disable
different unwinders, then we should probably move to a more generic
solution, and remove this patch.
this patch also reverts 3c3bb0580be0
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8434 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
temp adding completion
Guinevere Larsen [Thu, 14 Mar 2024 15:14:27 +0000 (16:14 +0100)]
gdb: Migrate frame unwinders to use C++ classes
Frame unwinders have historically been a structure populated with
callback pointers, so that architectures (or other specific unwinders)
could install their own way to handle the inferior. However, since
moving to C++, we could use polymorphism to get the same functionality
in a more readable way. Polymorphism also makes it simpler to add new
functionality to all frame unwinders, since all that's required is
adding it to the base class.
As part of the changes to add support to disabling frame unwinders,
this commit makes the first baby step in using polymorphism for the
frame unwinders, by making frame_unwind a virtual class, and adds a
couple of new classes. The main class added is frame_unwind_legacy,
which works the same as the previous structs, using function pointers
as callbacks. This class was added to allow the transition to happen
piecemeal. New unwinders should instead follow the lead of the other
classes implemented.
2 of the others, frame_unwind_python and frame_unwind_trampoline, were added
because it seemed simpler at the moment to do that instead of reworking
the dynamic allocation to work with the legacy class, and can be used as
an example to future implementations.
Finally, the cygwin unwinder was converted to a class since it was most
of the way there already.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Guinevere Larsen [Thu, 14 Mar 2024 15:14:26 +0000 (16:14 +0100)]
gdb: add "unwinder class" to frame unwinders
A future patch will add a way to disable certain unwinders based on
different characteristics. This patch aims to make it more convenient
to disable related unwinders in bulk, such as architecture specific
ones, by identifying all unwinders by which part of the code adds it.
The classes, and explanations, are as follows:
* GDB: An internal unwinder, added by GDB core, such as the unwinder
for dummy frames;
* EXTENSION: Unwinders added by extension languages;
* DEBUGINFO: Unwinders installed by the debug info reader;
* ARCH: Unwinders installed by the architecture specific code.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Guinevere Larsen [Thu, 14 Mar 2024 15:14:25 +0000 (16:14 +0100)]
gdb: make gdbarch store a vector of frame unwinders
Before this commit, all frame unwinders would be stored in the obstack
of a gdbarch and accessed by using the registry system. This made for
unwieldy code, and unnecessarily complex logic in the frame_unwinder
implementation, along with making frame_unwind structs be unable to have
non-trivial destructors.
Seeing as a future patch of this series wants to refactor the
frame_unwind struct to use inheritance, and we'd like to not restrict
the future derived classes on what destructors are allowed. In
preparation for that change, this commit changes the registry in gdbarch
to instead store an std::vector, which doesn't require using an obstack
and doesn't rely on a linked list.
There should be no user-visible changes.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
MayShao-oc [Fri, 17 Jan 2025 14:33:59 +0000 (15:33 +0100)]
x86: Add CpuGMISM2 and CpuGMICCS
There are separate CPUID feature bits for SM2 and CCS instructions.
CCS is the acronym of Chinese Cipher System, it includes SM3 and SM4
instructions. This patch adds CpuGMISM2 and CpuGMICCS to replace CpuGMI on
corresponding instructions.
gas/ChangeLog:
* config/tc-i386.c: Add gmism2 and gmiccs to replace gmi.
* doc/c-i386.texi: Ditto.
opcodes/ChangeLog:
* i386-gen.c: Add GMISM2 and GMICCS to replace GMI.
* i386-opc.h (enum i386_cpu): Add CpuGMISM2 and CpuGMICCS to
replace CpuGMI.
* i386-opc.tbl: Replace GMI with GMISM2 on sm2 instruction. Replace GMI
with GMICCS on sm3 and sm4 instructions.
* i386-tbl.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-init.h: Ditto.
Lulu Cai [Tue, 14 Jan 2025 13:13:01 +0000 (21:13 +0800)]
LoongArch: Allocate GOT entry for TLS DESC when -mno-relax is enabled
The type transition of TLSDESC is only done when -mrelax is enabled.
So when -mno-relax is enabled, keep GOT_TLS_GDESC to allocate the
GOT entry instead of just keeping GOT_TLS_IE.
Jan Beulich [Fri, 17 Jan 2025 09:28:15 +0000 (10:28 +0100)]
x86/APX: convert runtime special case to build-time one
cpu_flags_match() is a hot path. Move the special casing that b7267244a355 ("Support Intel AMX-MOVRS") added there to i386-gen, thus
affecting only build time performance.
Jan Beulich [Fri, 17 Jan 2025 09:27:54 +0000 (10:27 +0100)]
x86: have .insn correctly consider AVX10.2's 256-bit embedded rounding
Deriving operand size may no longer assume 512-bit vector size when
embedded rounding is in use. In fact it was apparently wrong to do so
in the first place, as that's not correct for scalar insns. Drop the
rounding type check altogether; we fall back to EVEX.LIG when no
suitable operand was specified anyway, later in the function (and, btw,
similarly for VEX encodings).
Nelson Chu [Tue, 14 Jan 2025 06:16:48 +0000 (14:16 +0800)]
RISC-V: PR32499, Fix PR18841 segfault caused by ifunc relocation ordering
Even though the relocation isn't IRELATIVE, it still should be come last if
refering to ifunc symbol. In order to get the ifunc relocs properly sorted
the correct class needs to be returned. The code mimics what has been done
for x86, sparc, aarch64 and arm32.
bfd/
PR 18841
PR 32499
* elfnn-riscv.c (riscv_reloc_type_class): Handle ifunc relocation
ordering, even though it's not IRELATIVE, it still should be come
last if refering ifunc symbol.
Alan Modra [Fri, 17 Jan 2025 07:27:48 +0000 (17:57 +1030)]
Silence asan warnings in resolve_symbol_value
The ".quad with division (fwdref)" gas test fails with asan warning
negation of -9223372036854775808 cannot be represented in type 'long int'
Fix this and another similar case.
* symbols.c (resolve_symbol_value): Cast "left" to valueT
before negating.
projects / thirdparty / binutils-gdb.git / log
