| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The pmuls encoding is incorrect -- it looks like a copy & paste error
from the padd pmuls variant. The SuperH software manual covers this.
On the flip side, the manual lists pwsb & pwad as insns that exist,
but no description of what they do, what the insn name means, or the
actual encoding. Our sim implementation stubs them both out as nops.
Let's mark the fields to avoid unused variable warnings.
|
|
Mark a few things static/const, and clean up trailing whitespace.
|
|
These should be using the BF52x set of ports, not BF51x.
|
|
|
|
Fix a few problems caught by compiler warnings:
* Some of the asr & lsr insns were setting up the c state flag,
but then forgetting to set it in the PSW. Add it like the other
asr & lsr variants.
* Some of the dmulh insns were multiplying one of the source regs
against itself instead of against the other source reg.
* The sat16_cmp parallel insn was using the wrong register in the
compare -- the reg1 src/dst pair are used in the sat16 op, and
the reg2 src/dst pair are used in the add op.
|
|
|
|
Currently, the overload handling in Ada assumes that any two array
types are compatible. However, this is obviously untrue, and a user
reported an oddity where comparing two Ada strings resulted in a call
to the "=" function for packed boolean arrays.
This patch improves the situation somewhat, by requiring that the two
arrays have the same arity and compatible base element types. This is
still over-broad, but it seems safe and is better than the status quo.
|
|
This changes ada_type_match to return bool.
|
|
2023-12-15 John David Anglin <danglin@gcc.gnu.org>
PR ld/31148
bfd/ChangeLog:
* elf32-hppa.c (elf32_hppa_finish_dynamic_symbol): Output
relative reloc only when eh->root.type is bfd_link_hash_defined
or bfd_link_hash_defweak.
|
|
Hi,
This patch contains a reformatting of -march option section in gas documentation.
For instance (see https://sourceware.org/binutils/docs-2.41/as.html#ARM-Options),
before all the options were on one line:
For armv8-a:
+crc: Enables CRC32 Extension. +simd: Enables VFP and NEON for Armv8-A. +crypto: Enables
Cryptography Extensions for Armv8-A, implies +simd. +sb: Enables Speculation Barrier
Instruction for Armv8-A. +predres: Enables Execution and Data Prediction Restriction
Instruction for Armv8-A. +nofp: Disables all FPU, NEON and Cryptography Extensions.
+nocrypto: Disables Cryptography Extensions.
Now, the readability is improved thanks to the itemization of the options:
For armv8-a:
+crc: Enables CRC32 Extension.
+simd: Enables VFP and NEON for Armv8-A.
+crypto: Enables Cryptography Extensions for Armv8-A, implies +simd.
+sb: Enables Speculation Barrier Instruction for Armv8-A.
+predres: Enables Execution and Data Prediction Restriction Instruction for Armv8-A.
+nofp: Disables all FPU, NEON and Cryptography Extensions.
+nocrypto: Disables Cryptography Extensions.
Ok for binutils-master? I don't have commit access so I need someone to commit on my behalf.
Regards,
Matthieu.
|
|
Hi,
This patch adds support for the Cortex-X3 CPU to binutils.
Gas regression testing for aarch64-none-linux-gnu target and found no regressions.
Ok for binutils-master? I don't have commit access so I need someone to commit on my behalf.
Regards,
Matthieu.
|
|
|
|
Otherwise intermediate subsection switches result in inconsistent
behavior. Leverage ELF's section change hook to switch state as
necessary, limiting overhead to the bare minimum when subsections aren't
used.
|
|
... after any (sub)section change. While certain existing target hooks
only look at now_seg, for a few others it looks as if failing to do so
could have caused anomalies if sub-sections were used. In any event a
subsequent x86 change is going to require the sub-section to be properly
in place at the time the hook is invoked.
This primarily means for obj_elf_section() to pass the new subsection
into change_section(), for it to be set right away (ahead of invoking
the hook).
Also adjust obj_elf_ident() to invoke the hook after all section
changes. (Note that obj_elf_version(), which also changes sections and
then changes them back, has no hook invocation at all so far, so none
are added. Presumably there is a reason for this difference in
behavior.)
|
|
No caller outside of obj-elf.c cares about the parameter - drop it by
introducing an obj-elf.c-internal wrapper.
While adding the new function parameter, take the opportunity and change
the adjacent boolean one to "bool".
|
|
ELF, COFF, and Mach-O all have custom handlers for .bss. Don't override
those; install a handler only for a.out.
|
|
This reverts commit 1f865bae65db9588f6994c02a92355bfb4e3d955. The
specification is going to by updated in a way rendering this change
wrong.
|
|
Now that ATTSyntax and ATTMnemonic aren't use in combination anymore,
fold them and IntelSyntax into a single, enum-like attribute. Note that
this shrinks i386_opcode_modifier back to 2 32-bit words (albeit that's
not for long, seeing in-flight additions for APX).
|
|
As noted in the context of d53e6b98a259 ("x86/Intel: correct disassembly
of fsub*/fdiv*") there's no such thing as Intel syntax without Intel
mnemonics. Enforce this on the assembler side, and disentangle command
line option handling on the disassembler side accordingly.
As a result in the opcode table specifying ATTMnemonic|ATTSyntax becomes
redundant with just ATTMnemonic. Drop the now meaningless ATTSyntax and
remove the then no longer accessible templates.
|
|
Some complain (by default) about isalpha shadowing ctype.h's isalpha().
Some also complain about signed/unsigned comparison a few lines later.
|
|
This is a small addendum to PR31124 "rodata in flash for
more AVR devices".
It adds some symbols so the startup code can set a lock
on the FLMAP bit field as specified by the user.
New symbols are introduced because otherwise, all the
computations / decisions would have to be performed at
run-time.
It approved, please apply to master.
Johann
--
ld/
PR 31124
* scripttempl/avr.sc: Adjust comments.
[MAYBE_FLMAP]: Add symbols __flmap_value and __flmap_value_with_lock.
Remove __flmap_lsl4.
|
|
The migration to local.mk in commit 0a129eb19a773d930d60b084209570f663db2053
accidentally listed the deps for all mloop steps as mloop.in instead of the
various variants that m32r uses.
Reported-by: Simon Marchi <simon.marchi@polymtl.ca>
|
|
The mloop.in code does this, but these variants do not. Use it to
avoid unused function warnings. The fast_p logic in these files
also looks off, but that'll require a bit more work to fixup.
CC m32r/mloopx.o
m32r/mloopx.c:37:1: error: ‘m32rxf_fill_argbuf_tp’ defined but not used [-Werror=unused-function]
37 | m32rxf_fill_argbuf_tp (const SIM_CPU *cpu, ARGBUF *abuf,
| ^~~~~~~~~~~~~~~~~~~~~
CC m32r/mloop2.o
m32r/mloop2.c:37:1: error: ‘m32r2f_fill_argbuf_tp’ defined but not used [-Werror=unused-function]
37 | m32r2f_fill_argbuf_tp (const SIM_CPU *cpu, ARGBUF *abuf,
| ^~~~~~~~~~~~~~~~~~~~~
Reported-by: Simon Marchi <simon.marchi@polymtl.ca>
Tested-By: Simon Marchi <simon.marchi@polymtl.ca>
|
|
When generating semantics.c from .igen source files, indenting the code
makes it more readable, but confuses compiler diagnostics. The latter
is a bit more important than the former, so bias towards that.
For example, with an introduced error, we can see w/gcc-13:
(before this change)
CC mn10300/semantics.o
../../../sim/mn10300/am33-2.igen: In function ‘semantic_dcpf_D1a’:
../../../sim/mn10300/am33-2.igen:11:5: error: ‘srcreg’ undeclared (first use in this function)
11 | srcreg = translate_rreg (SD_, RN2);
| ^~~~~~
(with this change)
CC mn10300/semantics.o
../../../sim/mn10300/am33-2.igen: In function ‘semantic_dcpf_D1a’:
../../../sim/mn10300/am33-2.igen:11:3: error: ‘srcreg’ undeclared (first use in this function)
11 | srcreg = translate_rreg (SD_, RN2);
| ^~~~~~
|
|
|
|
PR 31145
* bfd.c (BFD_IN_MEMORY): Mention that bim is malloc'd.
* format.c (io_reinit): Free BFD_IN_MEMORY iostream.
* opncls.c (_bfd_delete_bfd): Likewise.
(bfd_make_readable): Delete unnecessary code.
* bfd-in2.h: Regenerate.
|
|
Commit b05efa39b479 removed checks I added in commit f22f27f46c75 to
prevent segfaults when debug_info_p is NULL, which can be the case
with fuzzed objects. Restore those checks. Also, for dwo look at
rnglists_dwo rather than rnglists.
|
|
This commit adds support for ratified extensions:
'Zicntr' and 'Zihpm', Which are all implicitly depend on 'Zicsr'.
This is based on:
<https://github.com/riscv/riscv-isa-manual/releases/download/riscv-isa-release-056b6ff-2023-10-02/unpriv-isa-asciidoc.pdf>
bfd/ChangeLog:
* elfxx-riscv.c: Add 'Zicntr' and 'Zihpm' -> 'Zicsr'.
(riscv_supported_std_z_ext) Add 'Zicntr' and 'Zihpm' to the list.
|
|
|
|
Removed incorrect unnecessary code.
gprofng/ChangeLog
2023-12-13 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* src/collctrl.cc (set_synctrace): Fix -Wuse-after-free warning.
|
|
Spotted what appears to be a copy&paste error in string_option_def,
the code for string handling writes the address fetching callback
function into the option_def::var_address::enumeration location,
rather than option_def::var_address::string.
Of course, this works just fine as option_def::var_address is a union,
and all of its members are function pointers, so they're going to be
the same size on every target GDB cares about.
But it doesn't hurt to be correct, so fixed in this commit.
There should be no user visible changes after this commit.
|
|
This patch adds tests to exercise the previous patches' changes.
All three tests:
- aarch64-pseudo-unwind
- amd64-pseudo-unwind
- arm-pseudo-unwind
follow the same pattern, just with different registers.
The other test, arm-pseudo-unwind-legacy, tests the special case where
the unwind information contains an entry for a register considered a
pseudo-register by GDB.
Change-Id: Ic29ac040c5eb087b4a0d79f9d02f65b7979df30f
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-by: Luis Machado <luis.machado@arm.com>
Approved-By: Luis Machado <luis.machado@arm.com> (aarch64/arm)
Tested-By: Luis Machado <luis.machado@arm.com> (aarch64/arm)
|
|
Make arm use the new gdbarch_pseudo_register_write. This fixes writing
pseudo registers to non-current frames for that architecture.
Change-Id: Icb2a649ab6394817844230e9e94c3d0564d2f765
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-by: Luis Machado <luis.machado@arm.com>
|
|
Make arm use the "newer" gdbarch_pseudo_register_read_value. This fixes
reading pseudo registers in non-current frames on that architecture.
Change-Id: Ic4d3d5d96957a4addfa3443c7b567dc4a31794a9
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-by: Luis Machado <luis.machado@arm.com>
|
|
Make aarch64 use the new gdbarch_pseudo_register_write. This fixes
writing pseudo registers to non-current frames on this architecture.
Change-Id: Ic012a0b95ae728d45a7121f77a79d604c23a849e
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
It seems like the intention here is to read the contents of the ZA
register and only write part of it. However, there's no actual read of
the ZA register, so it looks like we'll write uninitialized bytes to the
target, for the portion of the raw register where we don't write the
pseudo register. Add a call to raw_read to fix this.
I don't know how to test this though.
Change-Id: I7548240bd4324f6a3b729a1ebf7502fae5a46e9e
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-by: Luis Machado <luis.machado@arm.com>
|
|
This is not necessary, but it seems more natural to me to make
aarch64_za_offsets_from_regnum return a za_offsets object, rather than
fill an instance passed by parameter.
Change-Id: I40a185f055727da887ce7774be193eef1f4b9147
Approved-by: Luis Machado <luis.machado@arm.com>
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
Make i386 and amd64 use the new gdbarch_pseudo_register_write. This
fixes writing to pseudo registers in non-current frames for those
architectures.
Change-Id: I4977e8fe12d2cef116f8834c34cdf6fec618554f
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
Add a new variant of gdbarch_pseudo_register_write that takes a
frame_info in order to write raw registers. Use this new method when
available:
- in put_frame_register, when trying to write a pseudo register to a given frame
- in regcache::cooked_write
No implementation is migrated to use this new method (that will come in
subsequent patches), so no behavior change is expected here.
The objective is to fix writing pseudo registers to non-current
frames. See previous commit "gdb: read pseudo register through
frame" for a more detailed explanation.
Change-Id: Ie7fe364a15a4d86c2ecb09de2b4baa08c45555ac
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
gdbarch_deprecated_pseudo_register_write
The next patch introduces a new variant of gdbarch_pseudo_register_write
that takes a frame instead of a regcache for implementations to write
raw registers. Rename to old one to make it clear it's deprecated.
Change-Id: If8872c89c6f8a1edfcab983eb064248fd5ff3115
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
For consistency with the declarations around.
Change-Id: I398266a61eae6e93fb7e306923009da9dd7f8fc4
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
Change gdbarch_pseudo_register_read_value to take a frame instead of a
regcache. The frame (and formerly the regcache) is used to read raw
registers needed to make up the pseudo register value. The problem with
using the regcache is that it always provides raw register values for
the current frame (frame 0).
Let's say the user wants to read the ebx register on amd64. ebx is a pseudo
register, obtained by reading the bottom half (bottom 4 bytes) of the
rbx register, which is a raw register. If the currently selected frame
is frame 0, it works fine:
(gdb) frame 0
#0 break_here_asm () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S:36
36 in /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S
(gdb) p/x $ebx
$1 = 0x24252627
(gdb) p/x $rbx
$2 = 0x2021222324252627
But if the user is looking at another frame, and the raw register behind
the pseudo register has been saved at some point in the call stack, then
we get a wrong answer:
(gdb) frame 1
#1 0x000055555555517d in caller () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S:56
56 in /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S
(gdb) p/x $ebx
$3 = 0x24252627
(gdb) p/x $rbx
$4 = 0x1011121314151617
Here, the value of ebx was computed using the value of rbx in frame 0
(through the regcache), it should have been computed using the value of
rbx in frame 1.
In other to make this work properly, make the following changes:
- Make dwarf2_frame_prev_register return nullptr if it doesn't know how
to unwind a register and that register is a pseudo register.
Previously, it returned `frame_unwind_got_register`, meaning, in our
example, "the value of ebx in frame 1 is the same as the value of ebx
in frame 0", which is obviously false. Return nullptr as a way to
say "I don't know".
- In frame_unwind_register_value, when prev_register (for instance
dwarf2_frame_prev_register) returns nullptr, and we are trying to
read a pseudo register, try to get the register value through
gdbarch_pseudo_register_read_value or gdbarch_pseudo_register_read.
If using gdbarch_pseudo_register_read, the behavior is known to be
broken. Implementations should be migrated to use
gdbarch_pseudo_register_read_value to fix that.
- Change gdbarch_pseudo_register_read_value to take a frame_info
instead of a regcache, update implementations (aarch64, amd64, i386).
In i386-tdep.c, I made a copy of i386_mmx_regnum_to_fp_regnum that
uses a frame instead of a regcache. The version using the regcache
is still used by i386_pseudo_register_write. It will get removed in
a subsequent patch.
- Add some helpers in value.{c,h} to implement the common cases of
pseudo registers: taking part of a raw register and concatenating
multiple raw registers.
- Update readable_regcache::{cooked_read,cooked_read_value} to pass the
current frame to gdbarch_pseudo_register_read_value. Passing the
current frame will give the same behavior as before: for frame 0, raw
registers will be read from the current thread's regcache.
Notes:
- I do not plan on changing gdbarch_pseudo_register_read to receive a
frame instead of a regcache. That method is considered deprecated.
Instead, we should be working on migrating implementations to use
gdbarch_pseudo_register_read_value instead.
- In frame_unwind_register_value, we still ask the unwinder to try to
unwind pseudo register values. It's apparently possible for the
debug info to provide information about [1] pseudo registers, so we
want to try that first, before falling back to computing them
ourselves.
[1] https://inbox.sourceware.org/gdb-patches/20180528174715.A954AD804AD@oc3748833570.ibm.com/
Change-Id: Id6ef1c64e19090a183dec050e4034d8c2394e7ca
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
Add value::allocate_register, to facilitate allocating a value
representing a register in a given frame (or rather, in the given
frame's previous frame). It will be used in a subsequent patch. I
changed one relatively obvious spot that could use it, to at least
exercise the code path.
Change-Id: Icd4960f5e471a74b657bb3596c88d89679ef3772
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
Similar to the previous patches, change get_frame_register_bytes to take
the "next frame" instead of "this frame".
Change-Id: Ie8f35042bfa6e93565fcefaee71b6b3903f0fe9f
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
Similar to the previous patches, change put_frame_register_bytes to take
the "next frame" instead of "this frame".
Change-Id: I27bcb26573686d99b231230823cff8db6405a788
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
Similar to the previous patches, change put_frame_register to take the
"next frame" instead of "this frame".
Change-Id: I062fd4663b8f54f0fc7bbf39c860b7341363821b
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
I was going to change frame_register to take the "next frame", but I
realized that doing so would make it a useless wrapper around
frame_register_unwind. So, just remove frame_register and replace uses
with frame_register_unwind.
Change-Id: I185868bc69f8e098124775d0550d069220a4678a
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
Some functions related to the handling of registers in frames accept
"this frame", for which we want to read or write the register values,
while other functions accept "the next frame", which is the frame next
to that. The later is needed because we sometimes need to read register
values for a frame that does not exist yet (usually when trying to
unwind that frame-to-be).
value_of_register and value_of_register_lazy both take "this frame",
even if what they ultimately want internally is "the next frame". This
is annoying if you are in a spot that currently has "the next frame" and
need to call one of these functions (which happens later in this
series). You need to get the previous frame only for those functions to
get the next frame again. This is more manipulations, more chances of
mistake.
I propose to change these functions (and a few more functions in the
subsequent patches) to operate on "the next frame". Things become a bit
less awkward when all these functions agree on which frame they take.
So, in this patch, change value_of_register_lazy and value_of_register
to take "the next frame" instead of "this frame". This adds a lot of
get_next_frame_sentinel_okay, but if we convert the user registers API
to also use "the next frame" instead of "this frame", it will get simple
again.
Change-Id: Iaa24815e648fbe5ae3c214c738758890a91819cd
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
Change put_frame_register to take an array_view instead of a raw
pointer.
Add an assertion to verify that the number of bytes we try to write
matches the length of the register.
Change-Id: Ib75a9c8a12b47e203097621643eaa2c1830591ae
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
|
|
I found this only by inspection: the myaddr pointer in
{get,put}_frame_register_bytes is reset to `buffer.data ()` at each
iteration. This means that we will always use the bytes at the
beginning of `buffer` to read or write to the registers, instead of
progressing in `buffer`.
Fix this by re-writing the functions to chip away the beginning of the
buffer array_view as we progress in reading or writing the data.
These bugs was introduced almost 3 years ago [1], and yet nobody
complained. I'm wondering which architecture relies on that register
"overflow" behavior (reading or writing multiple consecutive registers
with one {get,put}_frame_register_bytes calls), and in which situation.
I find these functions a bit dangerous, if a caller mis-calculates
things, it could end up silently reading or writing to the next
register, even if it's not the intent.
If I could change it, I would prefer to have functions specifically made
for that ({get,put}_frame_register_bytes_consecutive or something like
that) and make {get,put}_frame_register_bytes only able to write within
a single register (which I presume represents most of the use cases of
the current {get,put}_frame_register_bytes). If a caller mis-calculates
things and an overflow occurs while calling
{get,put}_frame_register_bytes, it would hit an assert. The problem is
knowing which callers rely on the overflow behavior and which don't.
[1] https://gitlab.com/gnutools/binutils-gdb/-/commit/bdec2917b1e94c7198ba39919f45060067952f43
Change-Id: I43bd4a9f7fa8419d388a2b20bdc57d652688ddf8
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
