Masking is not permitted for certain further insns, not falling in any
of the earlier categories. Introduce the Y macro (not expanding to any
output) to flag such cases.
Note that in a few cases entries already covered otherwise are converted
as well, to continue to allow sharing of the string literals.
Masking is not permitted in this case. See the code comment for how this
is being dealt with.
To avoid excess special casing of modes, have OP_M() call OP_E_memory()
directly.
While only zeroing-masking is possible in this case, this still requires
EVEX.z to be clear. Introduce a "global" flag right here, to be re-used
by checks which need to live in specific operand handlers.
Rather than corrupting disassmbly altogether, flag EVEX.z set as bad
when masking isn't in effect in the first place at the time the
destination operand is actually processed.
Only a few types in the Python API currently have __repr__()
implementations. This patch adds a few more of them. specifically: it
adds __repr__() implementations to gdb.Symbol, gdb.Architecture,
gdb.Block, gdb.Breakpoint, gdb.BreakpointLocation, and gdb.Type.
This makes it easier to play around the GDB Python API in the Python
interpreter session invoked with the 'pi' command in GDB, giving more
easily accessible tipe information to users.
An example of how this would look like:
(gdb) pi
>> gdb.lookup_type("char")
<gdb.Type code=TYPE_CODE_INT name=char>
>> gdb.lookup_global_symbol("main")
<gdb.Symbol print_name=main>
The gdb.Block.__repr__() method shows the first 5 symbols from the
block, and then a message to show how many more were elided (if any).
In the next commit we would like to have mdict_size return the number
of symbols in the dictionary, currently mdict_size is just a
heuristic, sometimes it returns the number of symbols, and sometimes
the number of buckets in a hashing dictionary (see size_hashed in
dictionary.c).
Currently this vague notion of size is good enough, the only place
mdict_size is used is in a maintenance command in order to print a
message containing the size of the dictionary ... so we don't really
care that the value isn't correct.
However, in the next commit we do want the size returned to be the
number of symbols in the dictionary, so this commit makes mdict_size
return the symbol count in all cases.
The new use is still not on a hot path -- it's going to be a Python
__repr__ method, so all I do in this commit is have size_hashed walk
the dictionary and count the entries, obviously this could be slow if
we have a large number of symbols, but for now I'm not worrying about
that case. We could always store the symbol count if we wanted, but
that would increase the size of every dictionary for a use case that
isn't going to be hit that often.
I've updated the text in 'maint print symbols' so that we don't talk
about the size being 'syms/buckets', but just 'symbols' now.
The code in md_apply_fix which tries to deduce from the operand type
which reloc to apply currently does the wrong thing for absolute
relocs which have been re-written by fixup_segment as pc-relative to
implement a subtraction of a local and an external symbol.
In all these cases we wrongly emit an absolute reloc because we ignore
the fx_pcrel flag in md_apply_fix. However, only for the last one we
actually support a pc relative relocation of the proper size and can
implement it accordingly. For the other 3 we have to issue an error.
foo:
cli 0(%r2),undef-foo
la %r2,undef-foo(%r2)
lay %r2,undef-foo(%r2)
lhi %r2,undef-foo
PyModule_AddObject steals a reference on success, but not on error,
which is why we have gdb_pymodule_addobject. I found one spot still
calling the former, which could in theory leak memory on failure.
This patch fixes this.
In the same function I found an unchecked call to
PyDict_SetItemString. This patch fixes this as well.
Approved-By: Andrew Burgess <aburgess@redhat.com>
The previous commit added the test gdb.arch/core-file-pid0.exp which
tests GDB's ability to load a core file containing threads with an
lwpid of 0, which is something we GDB can encounter when loading a
vmcore file -- a core file generated by the Linux kernel. The threads
with an lwpid of 0 represents idle cores.
While the previous commit added the test, which confirms GDB doesn't
crash when confronted with such a core file, there are still some
problems with GDB's handling of these core files. These problems all
originate from the fact that the core file (once opened by bfd)
contains multiple sections called .reg/0, these sections all
represents different threads (cpu cores in the original vmcore dump),
but GDB gets confused and thinks all of these .reg/0 sections are all
referencing the same thread.
Here is a GDB session on an x86-64 machine which loads the core file
from the gdb.arch/core-file-pid0.exp, this core file contains two
threads, both of which have a pid of 0:
$ ./gdb/gdb --data-directory ./gdb/data-directory/ -q
(gdb) core-file /tmp/x86_64-pid0-core.core
[New process 1]
[New process 1]
Failed to read a valid object file image from memory.
Core was generated by `./segv-mt'.
Program terminated with signal SIGSEGV, Segmentation fault.
The current thread has terminated
(gdb) info threads
Id Target Id Frame
2 process 1 0x00000000004017c2 in ?? ()
The current thread <Thread ID 1> has terminated. See `help thread'.
(gdb) maintenance info sections
Core file: `/tmp/x86_64-pid0-core.core', file type elf64-x86-64.
[0] 0x00000000->0x000012d4 at 0x00000318: note0 READONLY HAS_CONTENTS
[1] 0x00000000->0x000000d8 at 0x0000039c: .reg/0 HAS_CONTENTS
[2] 0x00000000->0x000000d8 at 0x0000039c: .reg HAS_CONTENTS
[3] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo/0 HAS_CONTENTS
[4] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo HAS_CONTENTS
[5] 0x00000000->0x00000140 at 0x000005c0: .auxv HAS_CONTENTS
[6] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file/0 HAS_CONTENTS
[7] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file HAS_CONTENTS
[8] 0x00000000->0x00000200 at 0x000007cc: .reg2/0 HAS_CONTENTS
[9] 0x00000000->0x00000200 at 0x000007cc: .reg2 HAS_CONTENTS
[10] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate/0 HAS_CONTENTS
[11] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate HAS_CONTENTS
[12] 0x00000000->0x000000d8 at 0x00000ea4: .reg/0 HAS_CONTENTS
[13] 0x00000000->0x00000200 at 0x00000f98: .reg2/0 HAS_CONTENTS
[14] 0x00000000->0x00000440 at 0x000011ac: .reg-xstate/0 HAS_CONTENTS
[15] 0x00400000->0x00401000 at 0x00002000: load1 ALLOC LOAD READONLY HAS_CONTENTS
[16] 0x00401000->0x004b9000 at 0x00003000: load2 ALLOC READONLY CODE
[17] 0x004b9000->0x004e5000 at 0x00003000: load3 ALLOC READONLY
[18] 0x004e6000->0x004ec000 at 0x00003000: load4 ALLOC LOAD HAS_CONTENTS
[19] 0x004ec000->0x004f2000 at 0x00009000: load5 ALLOC LOAD HAS_CONTENTS
[20] 0x012a8000->0x012cb000 at 0x0000f000: load6 ALLOC LOAD HAS_CONTENTS
[21] 0x7fda77736000->0x7fda77737000 at 0x00032000: load7 ALLOC READONLY
[22] 0x7fda77737000->0x7fda77f37000 at 0x00032000: load8 ALLOC LOAD HAS_CONTENTS
[23] 0x7ffd55f65000->0x7ffd55f86000 at 0x00832000: load9 ALLOC LOAD HAS_CONTENTS
[24] 0x7ffd55fc3000->0x7ffd55fc7000 at 0x00853000: load10 ALLOC LOAD READONLY HAS_CONTENTS
[25] 0x7ffd55fc7000->0x7ffd55fc9000 at 0x00857000: load11 ALLOC LOAD READONLY CODE HAS_CONTENTS
[26] 0xffffffffff600000->0xffffffffff601000 at 0x00859000: load12 ALLOC LOAD READONLY CODE HAS_CONTENTS
(gdb)
Notice when the core file is first loaded we see two lines like:
[New process 1]
And GDB reports:
The current thread has terminated
Which isn't what we'd expect from a core file -- the core file should
only contain threads that are live at the point of the crash, one of
which should be the current thread. The above message is reported
because GDB has deleted what we think is the current thread!
And in the 'info threads' output we are only seeing a single thread,
again, this is because GDB has deleted one of the threads.
Finally, the 'maintenance info sections' output shows the cause of all
our problems, two sections named .reg/0. When GDB sees the first of
these it creates a new thread. But, when we see the second .reg/0 GDB
tries to create another new thread, but this thread has the same
ptid_t as the first thread, so GDB deletes the first thread and
creates the second thread in its place.
Because both these threads are created with an lwpid of 0 GDB reports
these are 'New process NN' rather than 'New LWP NN' which is what we
would normally expect.
The previous commit includes a little more of the history of GDB
support in this area, but these problems were discussed on the mailing
list a while ago in this thread:
https://inbox.sourceware.org/gdb-patches/AANLkTi=zuEDw6qiZ1jRatkdwHO99xF2Qu+WZ7i0EQjef@mail.gmail.com/
In this commit I propose a solution to these problems.
What I propose is that GDB should spot when we have .reg/0 sections
and, when these are found, should rename these sections using some
unique non-zero lwpid.
Note in the above output we also have sections like .reg2/0 and
.reg-xstate/0, these are additional register sets, this commit also
renumbers these sections inline with their .reg section.
The user is warned that some section renumbering has been performed.
GDB takes care to ensure that the new numbers assigned are unique and
don't clash with any of the pid's that might already be in use --
remember, in a real vmcore file, 0 is used to indicate an idle core,
non-idle cores will have the pid of whichever process was running on
that core, so we don't want GDB to assign an lwpid that clashes with
an actual pid that is in use in the core file.
After this commit here's the updated GDB session output:
$ ./gdb/gdb --data-directory ./gdb/data-directory/ -q
(gdb) core-file /tmp/x86_64-pid0-core.core
warning: found threads with pid 0, assigned replacement Target Ids: LWP 1, LWP 2
[New LWP 1]
[New LWP 2]
Failed to read a valid object file image from memory.
Core was generated by `./segv-mt'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00000000004017c2 in ?? ()
[Current thread is 1 (LWP 1)]
(gdb) info threads
Id Target Id Frame
* 1 LWP 1 0x00000000004017c2 in ?? ()
2 LWP 2 0x000000000040dda5 in ?? ()
(gdb) maintenance info sections
Core file: `/tmp/x86_64-pid0-core.core', file type elf64-x86-64.
[0] 0x00000000->0x000012d4 at 0x00000318: note0 READONLY HAS_CONTENTS
[1] 0x00000000->0x000000d8 at 0x0000039c: .reg/1 HAS_CONTENTS
[2] 0x00000000->0x000000d8 at 0x0000039c: .reg HAS_CONTENTS
[3] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo/1 HAS_CONTENTS
[4] 0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo HAS_CONTENTS
[5] 0x00000000->0x00000140 at 0x000005c0: .auxv HAS_CONTENTS
[6] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file/1 HAS_CONTENTS
[7] 0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file HAS_CONTENTS
[8] 0x00000000->0x00000200 at 0x000007cc: .reg2/1 HAS_CONTENTS
[9] 0x00000000->0x00000200 at 0x000007cc: .reg2 HAS_CONTENTS
[10] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate/1 HAS_CONTENTS
[11] 0x00000000->0x00000440 at 0x000009e0: .reg-xstate HAS_CONTENTS
[12] 0x00000000->0x000000d8 at 0x00000ea4: .reg/2 HAS_CONTENTS
[13] 0x00000000->0x00000200 at 0x00000f98: .reg2/2 HAS_CONTENTS
[14] 0x00000000->0x00000440 at 0x000011ac: .reg-xstate/2 HAS_CONTENTS
[15] 0x00400000->0x00401000 at 0x00002000: load1 ALLOC LOAD READONLY HAS_CONTENTS
[16] 0x00401000->0x004b9000 at 0x00003000: load2 ALLOC READONLY CODE
[17] 0x004b9000->0x004e5000 at 0x00003000: load3 ALLOC READONLY
[18] 0x004e6000->0x004ec000 at 0x00003000: load4 ALLOC LOAD HAS_CONTENTS
[19] 0x004ec000->0x004f2000 at 0x00009000: load5 ALLOC LOAD HAS_CONTENTS
[20] 0x012a8000->0x012cb000 at 0x0000f000: load6 ALLOC LOAD HAS_CONTENTS
[21] 0x7fda77736000->0x7fda77737000 at 0x00032000: load7 ALLOC READONLY
[22] 0x7fda77737000->0x7fda77f37000 at 0x00032000: load8 ALLOC LOAD HAS_CONTENTS
[23] 0x7ffd55f65000->0x7ffd55f86000 at 0x00832000: load9 ALLOC LOAD HAS_CONTENTS
[24] 0x7ffd55fc3000->0x7ffd55fc7000 at 0x00853000: load10 ALLOC LOAD READONLY HAS_CONTENTS
[25] 0x7ffd55fc7000->0x7ffd55fc9000 at 0x00857000: load11 ALLOC LOAD READONLY CODE HAS_CONTENTS
[26] 0xffffffffff600000->0xffffffffff601000 at 0x00859000: load12 ALLOC LOAD READONLY CODE HAS_CONTENTS
(gdb)
Notice the new warning which is issued when the core file is being
loaded. The threads are announced as '[New LWP NN]', and we see two
threads in the 'info threads' output. The 'maintenance info sections'
output shows the result of the section renaming.
The gdb.arch/core-file-pid0.exp test has been update to check for the
improved GDB output.
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
This patch contains a test for this commit:
commit c820c52a91
Date: Fri Aug 6 19:45:58 2010 +0000
* thread.c (add_thread_silent): Use null_ptid instead of
minus_one_ptid while getting rid of stale inferior_ptid.
This is another test that has been carried in the Fedora GDB tree for
some time, and I thought that it would be worth merging to master. I
don't believe there is any test like this currently in the testsuite.
The original issue was reported in this thread:
https://inbox.sourceware.org/gdb-patches/AANLkTi=zuEDw6qiZ1jRatkdwHO99xF2Qu+WZ7i0EQjef@mail.gmail.com/
The problem was that when GDB was used to open a vmcore (core file)
image generated by the Linux kernel GDB would (sometimes) crash with
an assertion failure:
thread.c:884: internal-error: switch_to_thread: Assertion `inf != NULL' failed.
To understand what's going on we need some background; a vmcore file
represents each processor core in the same way that a standard
application core file represents threads. Thus, we might say, a
vmcore file represents cores as threads.
When writing a vmcore file, the kernel will store the pid of the
process currently running on that core as the thread's lwpid.
However, if a core is idle, with no process currently running on it,
then the lwpid for that thread is stored as 0 in the vmcore file. If
multiple cores are idle then multiple threads will have a lwpid of 0.
Back in 2010, the original issue reported tried to change the kernel's
behaviour in this thread:
https://lkml.org/lkml/2010/8/3/75
This change was rejected by the kernel team, the current
behaviour (lwpid of 0) was considered correct. I've checked the
source of a recent kernel. The code mentioned in the lkml.org posting
has moved, it's now in the function crash_save_cpu in the file
kernel/kexec_core.c, but the general behaviour is unchanged, an idle
core will have an lwpid of 0, so I think GDB still needs to be able to
handle this case.
When GDB loads a vmcore file (which is handled just like any other
core file) the sections are processed in core_open to generate the
threads for the core file. The processing is done by calling
add_to_thread_list, a function which looks for sections named .reg/NN
where NN is the lwpid of the thread, GDB then builds a ptid_t for the
new thread and calls add_thread.
Remember, in our case the lwpid is 0. Now for the first thread this
is fine, if a little weird, 0 isn't usually a valid lwpid, but that's
OK, GDB creates a thread with lwpid of 0 and carries on.
When we find the next thread (core) with lwpid of 0, we attempt to
create another thread with an lwpid of 0. This of course clashes with
the previously created thread, they have the same ptid_t, so GDB tries
to delete the first thread.
And it was within this thread delete code that we triggered a bug
which would then cause GDB to assert -- when deleting we tried to
switch to a thread with minus_one_ptid, this resulted in a call to
find_inferior_pid (passing in minus_one_ptid's pid, which is -1), the
find_inferior_pid call fails and returns NULL, which then triggered an
assert in switch_to_thread.
The actual details of the why the assert triggered are really not
important. What's important (I think) is that a vmcore file might
have this interesting lwpid of 0 characteristic, which isn't something
we see in "normal" application core files, and it is this that I think
we should be testing.
Now, you might be thinking: isn't deleting the first thread the wrong
thing to do? If the vmcore file has two threads that represent two
cores, and both have an lwpid of 0 (indicating both cores are idle),
then surely GDB should still represent this as two threads? You're
not wrong. This was mentioned by Pedro in the original GDB mailing
list thread here:
https://inbox.sourceware.org/gdb-patches/201008061057.03037.pedro@codesourcery.com/
This is indeed a problem, and this problem is still present in GDB
today. I plan to try and address this in a later commit, however,
this first commit is about getting a test in place to confirm that GDB
at a minimum doesn't crash when loading such a vmcore file.
And so, finally, what's in this commit?
This commit contains a new test. The test doesn't actually contain a
vmcore file. Instead I've created a standard application core file
that contains two threads, and then manually edited the core file to
set the lwpid of each thread to 0.
To further reduce the size of the core file (as it will be stored in
git), I've zeroed all of the LOAD-able segments in the core file.
This test really doesn't care about that part of the core file, we
only really care about loading the register's, this is enough to
confirm that the GDB doesn't crash.
Obviously as the core file is pre-generated, this test is architecture
specific. There are already a few tests in gdb.arch/ that include
pre-generate core files. Just as those existing tests do, I've
compressed the core file with bzip2, which reduces it to just 750
bytes. I have structured the test so that if/when this patch is
merged I can add some additional core files for other architectures,
however, these are not included in this commit.
The test simply expands the core file, and then loads it into GDB.
One interesting thing to note is that GDB reports the core file
loading like this:
(gdb) core-file ./gdb/testsuite/outputs/gdb.arch/core-file-pid0/core-file-pid0.x86-64.core
[New process 1]
[New process 1]
Failed to read a valid object file image from memory.
Core was generated by `./segv-mt'.
Program terminated with signal SIGSEGV, Segmentation fault.
The current thread has terminated
(gdb)
There's two interesting things here: first, the repeated "New process
1" message. This is caused because linux_core_pid_to_str reports
anything with an lwpid of 0 as a process, rather than an LWP. And
second, the "The current thread has terminated" message. This is
because the first thread in the core file is the current thread, but
when GDB loads the second thread (which also has lwpid 0) this causes
the first thread to be deleted, as a result GDB thinks that the
current (first) thread has terminated.
As I said previously, both of these problems are a result of the lwpid
0 aliasing, which is not being fixed in this commit -- this commit is
just confirming that GDB doesn't crash when loading this core file.
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
I noticed that in corelow.c, when a core file is opened, both the
thread and inferior setup is done in add_to_thread_list. In this
patch I propose hoisting the inferior setup out of add_to_thread_list
into core_target_open.
The only thing about this change that gave me cause for concern is
that in add_to_thread_list, we only setup the inferior after finding
the first section with a name like ".reg/NN". If we find no such
section then the inferior will never be setup.
Is this important?
Well, I don't think so. Back in core_target_open, if there is no
current thread (which there will not be if no ".reg/NN" section was
found), then we look for a thread in the current inferior. If there
are no threads (which there will not be if no ".reg/NN" is found),
then we once again setup the current inferior.
What I think this means, is that, in all cases, the current inferior
will end up being setup. By moving the inferior setup code earlier in
core_target_open and making it non-conditional, we can remove the
later code that sets up the inferior, we now know this will always
have been done.
There should be no user visible changes after this commit.
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
Currently we have three instruction classes defined for Zvkh[a,b]:
- INSN_CLASS_ZVKNHA
- INSN_CLASS_ZVKNHB
- INSN_CLASS_ZVKNHA_OR_ZVKNHB
The encodings of all instructions in Zvknh[a,b] are identical.
Therefore, we don't need the individual instruction classes
and can remove them.
This patch also adds the missing support of the combined instruction
class in riscv_multi_subset_supports_ext().
Fixes: 62edb233ef ("RISC-V: Add support for the Zvknh[a,b] ISA extensions")
Reported-By: Nelson Chu <nelson@rivosinc.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Formerly an include of libbfd.h was added in commit 56576f4a72
("LoongArch: gas: Add support for linker relaxation."), in order to
allow calling _bfd_read_unsigned_leb128 from gas, but doing so broke
shared builds. Commit d2fddb6d78 fixed this reference but did not
remove the now unnecessary inclusion of libbfd.h. The gas_assert macro
expands into a conditional call to abort(), but "abort" is re-defined to
_bfd_abort in libbfd.h, so the extra include breaks any gas_assert
usage, and should be removed.
gas/ChangeLog:
* config/tc-loongarch.c: Don't include libbfd.h.
Fixes: d2fddb6d78 ("LoongArch: Fix ld "undefined reference" error with --enable-shared")
Signed-off-by: WANG Xuerui <git@xen0n.name>
opcodes/ChangeLog:
* loongarch-opc.c: Mark the offset operands as "so" for
{,x}v{ld,st}, {,x}v{ldrepl,stelm}.[bhwd], and {ld,st}[lr].[wd].
Signed-off-by: WANG Xuerui <git@xen0n.name>
In our GUI project (https://savannah.gnu.org/projects/gprofng-gui), we use
the output of gprofng to display the data. Sometimes this data is corrupted.
gprofng/ChangeLog
2023-06-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* src/ipc.cc (ipc_doWork): Fix data race.
* src/ipcio.cc (IPCresponse::print): Fix data race.
Remove unused variables and functions.
* src/ipcio.h: Declare two variables.
* src/StringBuilder.cc (StringBuilder::write): New function.
* src/StringBuilder.h: Likewise.
This commit adds the recently added support of the RISC-V vector crypto
extensions to the NEWS file.
binutils/ChangeLog:
* NEWS: Announce new RISC-V vector crypto extensions.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Zvksc is part of the vector crypto extensions.
Zvksc is shorthand for the following set of extensions:
- Zvks
- Zvbc
bfd/ChangeLog:
* elfxx-riscv.c: Define Zvksc extension.
gas/ChangeLog:
* testsuite/gas/riscv/zvksc.d: New test.
* testsuite/gas/riscv/zvksc.s: New test.
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Zvknc is part of the vector crypto extensions.
Zvknc is shorthand for the following set of extensxions:
- Zvkn
- Zvbc
bfd/ChangeLog:
* elfxx-riscv.c: Define Zvknc extension.
gas/ChangeLog:
* testsuite/gas/riscv/zvknc.d: New test.
* testsuite/gas/riscv/zvknc.s: New test.
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Zvksg is part of the vector crypto extensions.
Zvksg is shorthand for the following set of extensions:
- Zvks
- Zvkg
bfd/ChangeLog:
* elfxx-riscv.c: Define Zvksg extension.
gas/ChangeLog:
* testsuite/gas/riscv/zvksg.d: New test.
* testsuite/gas/riscv/zvksg.s: New test.
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Zvks is part of the vector crypto extensions.
Zvks is shorthand for the following set of extensions:
- Zvksed
- Zvksh
- Zvbb
- Zvkt
bfd/ChangeLog:
* elfxx-riscv.c: Define Zvks extension.
gas/ChangeLog:
* testsuite/gas/riscv/zvks.d: New test.
* testsuite/gas/riscv/zvks.s: New test.
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Zvkng is part of the vector crypto extensions.
Zvkng is shorthand for the following set of extensions:
- Zvkn
- Zvkg
bfd/ChangeLog:
* elfxx-riscv.c: Define Zvkng extension.
gas/ChangeLog:
* testsuite/gas/riscv/zvkng.d: New test.
* testsuite/gas/riscv/zvkng.s: New test.
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Certain extensions require two levels of implications. For example,
zvkng implies zvkn and zvkn implies zvkned. Enabling zvkng should also
enable zvkned.
This patch fixes this behavior.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_parse_add_implicit_subsets): Allow nested
implications for extensions.
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Zvkn is part of the vector crypto extensions.
Zvkn is shorthand for the following set of extensions:
- Zvkned
- Zvknhb
- Zvbb
- Zvkt
bfd/ChangeLog:
* elfxx-riscv.c: Define Zvkn extension.
gas/ChangeLog:
* testsuite/gas/riscv/zvkn.d: New test.
* testsuite/gas/riscv/zvkn.s: New test.
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Zvksh is part of the vector crypto extensions.
This extension adds the following instructions:
- vsm3me.vv
- vsm3c.vi
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
class support for Zvksh.
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* testsuite/gas/riscv/zvksh.d: New test.
* testsuite/gas/riscv/zvksh.s: New test.
include/ChangeLog:
* opcode/riscv-opc.h (MATCH_VSM3C_VI): New.
(MASK_VSM3C_VI): New.
(MATCH_VSM3ME_VV): New.
(MASK_VSM3ME_VV): New.
(DECLARE_INSN): New.
* opcode/riscv.h (enum riscv_insn_class): Add instruction class
support for Zvksh.
opcodes/ChangeLog:
* riscv-opc.c: Add Zvksh instructions.
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Zvksed is part of the vector crypto extensions.
This extension adds the following instructions:
- vsm4k.vi
- vsm4r.[vv,vs]
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
class support for Zvksed.
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* testsuite/gas/riscv/zvksed.d: New test.
* testsuite/gas/riscv/zvksed.s: New test.
include/ChangeLog:
* opcode/riscv-opc.h (MATCH_VSM4K_VI): New.
(MASK_VSM4K_VI): New.
(MATCH_VSM4R_VS): New.
(MASK_VSM4R_VS): New.
(MATCH_VSM4R_VV): New.
(MASK_VSM4R_VV): New.
(DECLARE_INSN): New.
* opcode/riscv.h (enum riscv_insn_class): Add instruction class
support for Zvksed.
opcodes/ChangeLog:
* riscv-opc.c: Add Zvksed instructions.
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Zvknh[a,b] are parts of the vector crypto extensions.
This extension adds the following instructions:
- vsha2ms.vv
- vsha2c[hl].vv
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
class support for Zvknh[a,b].
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* testsuite/gas/riscv/zvknha.d: New test.
* testsuite/gas/riscv/zvknha_zvknhb.s: New test.
* testsuite/gas/riscv/zvknhb.d: New test.
include/ChangeLog:
* opcode/riscv-opc.h (MATCH_VSHA2CH_VV): New.
(MASK_VSHA2CH_VV): New.
(MATCH_VSHA2CL_VV): New.
(MASK_VSHA2CL_VV): New.
(MATCH_VSHA2MS_VV): New.
(MASK_VSHA2MS_VV): New.
(DECLARE_INSN): New.
* opcode/riscv.h (enum riscv_insn_class): Add instruction class
support for Zvknh[a,b].
opcodes/ChangeLog:
* riscv-opc.c: Add Zvknh[a,b] instructions.
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Zvkg is part of the vector crypto extensions.
This extension adds the following instructions:
- vghsh.vv
- vgmul.vv
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
class support for Zvkg.
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* testsuite/gas/riscv/zvkg.d: New test.
* testsuite/gas/riscv/zvkg.s: New test.
include/ChangeLog:
* opcode/riscv-opc.h (MATCH_VGHSH_VV): New.
(MASK_VGHSH_VV): New.
(MATCH_VGMUL_VV): New.
(MASK_VGMUL_VV): New.
(DECLARE_INSN): New.
* opcode/riscv.h (enum riscv_insn_class): Add instruction class
support for Zvkg.
opcodes/ChangeLog:
* riscv-opc.c: Add Zvkg instructions.
Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Simon pointed out that my agent expression C++-ification patches
caused a regression with the native-gdbserver target board. The bug
is that append_const is supposed to write in big-endian order, but I
switched this by mistake.
We picked up support for a few new extensions over the last weeks
(this may need further updating prior to the next release), list them
in the NEWS file.
binutils/ChangeLog:
* binutils/NEWS: announce suuport for the new RISC-V
extensions (Zicond, Zfa, XVentanaCondOps).
Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
This patch adds support for the RISC-V Zfa extension,
which introduces additional floating-point instructions:
* fli (load-immediate) with pre-defined immediates
* fminm/fmaxm (like fmin/fmax but with different NaN behaviour)
* fround/froundmx (round to integer)
* fcvtmod.w.d (Modular Convert-to-Integer)
* fmv* to access high bits of FP registers in case XLEN < FLEN
* fleq/fltq (quiet comparison instructions)
Zfa defines its instructions in combination with the following
extensions:
* single-precision floating-point (F)
* double-precision floating-point (D)
* quad-precision floating-point (Q)
* half-precision floating-point (Zfh)
This patch is based on an earlier version from Tsukasa OI:
https://sourceware.org/pipermail/binutils/2022-September/122939.html
Most significant change to that commit is the switch from the rs1-field
value to the actual floating-point value in the last operand of the fli*
instructions. Everything that strtof() can parse is accepted and
the '%a' printf specifier is used to output hex floating-point literals
in the disassembly.
The Zfa specification is frozen (and has passed public review). It is
available as a chapter in "The RISC-V Instruction Set Manual: Volume 1":
https://github.com/riscv/riscv-isa-manual/releases
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
class support for 'Zfa' extension.
(riscv_multi_subset_supports_ext): Likewise.
(riscv_implicit_subsets): Add 'Zfa' -> 'F' dependency.
gas/ChangeLog:
* config/tc-riscv.c (flt_lookup): New helper to lookup a float value
in an array.
(validate_riscv_insn): Add 'Wfv' as new format string directive.
(riscv_ip): Likewise.
* doc/c-riscv.texi: Add floating-point chapter and describe
limiations of the Zfa FP literal parsing.
* testsuite/gas/riscv/zfa-32.d: New test.
* testsuite/gas/riscv/zfa-32.s: New test.
* testsuite/gas/riscv/zfa-64.d: New test.
* testsuite/gas/riscv/zfa-64.s: New test.
* testsuite/gas/riscv/zfa-fail.d: New test.
* testsuite/gas/riscv/zfa-fail.l: New test.
* testsuite/gas/riscv/zfa-fail.s: New test.
* testsuite/gas/riscv/zfa.d: New test.
* testsuite/gas/riscv/zfa.s: New test.
* testsuite/gas/riscv/zfa.s: New test.
* opcode/riscv-opc.h (MATCH_FLI_H): New.
(MASK_FLI_H): New.
(MATCH_FMINM_H): New.
(MASK_FMINM_H): New.
(MATCH_FMAXM_H): New.
(MASK_FMAXM_H): New.
(MATCH_FROUND_H): New.
(MASK_FROUND_H): New.
(MATCH_FROUNDNX_H): New.
(MASK_FROUNDNX_H): New.
(MATCH_FLTQ_H): New.
(MASK_FLTQ_H): New.
(MATCH_FLEQ_H): New.
(MASK_FLEQ_H): New.
(MATCH_FLI_S): New.
(MASK_FLI_S): New.
(MATCH_FMINM_S): New.
(MASK_FMINM_S): New.
(MATCH_FMAXM_S): New.
(MASK_FMAXM_S): New.
(MATCH_FROUND_S): New.
(MASK_FROUND_S): New.
(MATCH_FROUNDNX_S): New.
(MASK_FROUNDNX_S): New.
(MATCH_FLTQ_S): New.
(MASK_FLTQ_S): New.
(MATCH_FLEQ_S): New.
(MASK_FLEQ_S): New.
(MATCH_FLI_D): New.
(MASK_FLI_D): New.
(MATCH_FMINM_D): New.
(MASK_FMINM_D): New.
(MATCH_FMAXM_D): New.
(MASK_FMAXM_D): New.
(MATCH_FROUND_D): New.
(MASK_FROUND_D): New.
(MATCH_FROUNDNX_D): New.
(MASK_FROUNDNX_D): New.
(MATCH_FLTQ_D): New.
(MASK_FLTQ_D): New.
(MATCH_FLEQ_D): New.
(MASK_FLEQ_D): New.
(MATCH_FLI_Q): New.
(MASK_FLI_Q): New.
(MATCH_FMINM_Q): New.
(MASK_FMINM_Q): New.
(MATCH_FMAXM_Q): New.
(MASK_FMAXM_Q): New.
(MATCH_FROUND_Q): New.
(MASK_FROUND_Q): New.
(MATCH_FROUNDNX_Q): New.
(MASK_FROUNDNX_Q): New.
(MATCH_FLTQ_Q): New.
(MASK_FLTQ_Q): New.
(MATCH_FLEQ_Q): New.
(MASK_FLEQ_Q): New.
(MATCH_FCVTMOD_W_D): New.
(MASK_FCVTMOD_W_D): New.
(MATCH_FMVH_X_D): New.
(MASK_FMVH_X_D): New.
(MATCH_FMVH_X_Q): New.
(MASK_FMVH_X_Q): New.
(MATCH_FMVP_D_X): New.
(MASK_FMVP_D_X): New.
(MATCH_FMVP_Q_X): New.
(MASK_FMVP_Q_X): New.
(DECLARE_INSN): New.
* opcode/riscv.h (enum riscv_insn_class): Add instruction
classes for the Zfa extension.
opcodes/ChangeLog:
* riscv-dis.c (print_insn_args): Add support for
new format string directive 'Wfv'.
* riscv-opc.c: Add Zfa instructions.
Co-Developed-by: Tsukasa OI <research_trasio@irq.a4lg.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Co-Developed-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>
