I needed to use gdbreplay today. It didn't work quite right, and
using "set debug remote 1" showed that gdb was rejecting some
responses like:
[remote] Sending packet: $vCont?#49
[remote] Junk: #vCont?
[remote] Junk: 8vCont?
[remote] Junk: 3vCont?
[remote] Received Ack
The checksum recalculation seems to have gone wrong. Looking at the
code, it seems like 'where_csum' is calculated inconsistently: in the
main loop it is after the '#' but in the "== 0" case it is before the
'#'.
This patch fixes the problem and also avoids a string copy.
CC: Alexandra Hájková <ahajkova@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
Add new DWARF5 language codes to gdb/dwarf2/read.c where
they are converted to GDB language names. The codes
were added to include/dwarf.h by syncing with gcc, Ada language
codes were added to dwarf.h earlier.
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
The IBM z/Architecture Principles of Operation [1] specifies that the
R1 operand of the may and mayr instructions designates may designate
either the lower- or higher-numbered register of a floating-point-
register (FPR) pair.
[1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
gdb/
* s390-tdep.c (s390_process_record): may/mayr operand R1 may
designate lower- or higher numbered register of FPR pair.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
If the '-name soname' option is used, the fake '<Total>' function is expanded
with the name loadobject.
gprofng/ChangeLog
2024-12-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* src/Hist_data.cc (Hist_data::sort): Fix sorting.
The test-case gdb.dap/scopes.exp contains the following outdated comment:
...
# setVariable isn't implemented yet, so use the register name.
...
Now that setVariable is implemented, use it to set variable scalar, and remove
the bit that sets the first register. That part is known to fail on s390x,
because the first register isn't writeable [1].
Tested on x86_64-linux.
Suggested-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/pipermail/gdb-patches/2024-December/213823.html
With test-case gdb.dap/step-out.exp on s390x-linux, I get:
...
>>> {"seq": 7, "type": "request", "command": "scopes", "arguments": {"frameId": 0}}
Content-Length: 569^M
^M
{"request_seq": 7, "type": "response", "command": "scopes", "body": {"scopes": [{"variablesReference": 1, "name": "Locals", "presentationHint": "locals", "expensive": false, "namedVariables": 1, "line": 35, "source": {"name": "step-out.c", "path": "/home/vries/gdb/src/gdb/testsuite/gdb.dap/step-out.c"}}, {"variablesReference": 2, "name": "Registers", "presentationHint": "registers", "expensive": false, "namedVariables": 114, "line": 35, "source": {"name": "step-out.c", "path": "/home/vries/gdb/src/gdb/testsuite/gdb.dap/step-out.c"}}]}, "success": true, "seq": 21}PASS: gdb.dap/step-out.exp: get scopes success
FAIL: gdb.dap/step-out.exp: three scopes
...
The problem is that the test-case expects three scopes:
...
lassign $scopes scope reg_scope return_scope
...
but the return_scope is missing because this doesn't work:
...
$ gdb -q -batch outputs/gdb.dap/step-out/step-out \
-ex "b function_breakpoint_here" \
-ex run \
-ex finish
...
Value returned has type: struct result. Cannot determine contents
...
This is likely caused by a problem in gdb, but there's nothing wrong the DAP
support.
Fix this by:
- allowing two scopes, and
- declaring the tests of return_scope unsupported.
Tested on s390x-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Since commit e69d35f45e ("Use ui-out table in "maint print reggroups""),
test-case gdb.python/py-arch-reg-groups.exp fails with check-read1:
...
FAIL: $exp: Same number of registers groups found
FAIL: $exp: all register groups match
...
Fix this by adding a gdb_test_multiple clause that matches the command.
Tested on x86_64-linux.
As per the spec (Section 7.5.10, LoongArch Reference Manual Vol. 1),
LoongArch machines are not limited in page size choices, and currently
page sizes of 4KiB, 16KiB and 64KiB are supported by mainline Linux.
While 16KiB is the most common, the current BFD code says it is the
maximum; this is not correct, and as an effect, almost all existing
binaries are incompatible with a 64KiB kernel because the sections are
not sufficiently aligned, while being totally fine otherwise.
This is needlessly complicating integration testing [1].
This patch fixes the inconsistency, and also brings BFD behavior in line
with that of LLD [2].
[1] https://github.com/loongson-community/discussions/issues/47
[2] https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/lld/ELF/Arch/LoongArch.cpp#L174-L183
bfd/
* elfnn-loongarch.c (ELF_MAXPAGESIZE): Bump to 64KiB.
(ELF_MINPAGESIZE): Define as 4KiB.
(ELF_COMMONPAGESIZE): Define as 16KiB.
ld/
* testsuite/ld-loongarch-elf/64_pcrel.d: Update assertions after
changing the target max page size to 64KiB.
* testsuite/ld-loongarch-elf/data-got.d: Likewise.
* testsuite/ld-loongarch-elf/desc-relex.d: Likewise.
* testsuite/ld-loongarch-elf/relax-align-ignore-start.d: Likewise.
* testsuite/ld-loongarch-elf/tlsdesc_abs.d: Make the fuzzy match work
as intended by not checking exact instruction words.
* testsuite/ld-loongarch-elf/tlsdesc_extreme.d: Likewise.
Signed-off-by: WANG Xuerui <git@xen0n.name>
Using r0 as a base address register in the ROP hashst and hashchk instructions
is invalid. Modify the assembler to catch that illegal use and emit an error.
opcodes/
* ppc-opc.c (insert_ras): Update error message and function comment.
(powerpc_opcodes) <hashst, hashstp, hashchk, hashchkp>: Use RAS.
We discovered that attempting to print a very large string-like array
would succeed on the CLI, but in DAP would cause the "variables"
request to fail with:
value requires 67038491 bytes, which is more than max-value-size
This turns out to be a limitation in Value.format_string, which
de-lazy-ifies the value.
This patch fixes this problem by introducing a new NoOpStringPrinter
class, and then using it for string-like values. This printer returns
a lazy string, which solves the problem.
Note there are some special cases where we do not want to return a
lazy string. I've documented these in the code. I considered making
gdb.Value.lazy_string handle these cases -- for example it could
return 'self' rather than a lazy string in some situations -- but this
approach was simpler.
gdbpy_create_lazy_string_object will throw an exception if you pass it
a NULL pointer without also setting length=0 -- the default,
length==-1, will fail. This seems bizarre. Furthermore, it doesn't
make sense to do this check for array types, as an array can have a
zero length. This patch cleans up the check and makes it specific to
TYPE_CODE_PTR.
Currently, gdb.Value.lazy_string will allow the conversion of any
object to a "lazy string". However, this was never the intent and is
weird besides. This patch changes this code to correctly throw an
exception in the non-matching cases.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20769
I added a new test using gdb_py_test_silent_cmd, and then was
surprised to find out that the new test passed -- it caused a Python
exception and I had expected it to fail. This patch fixes this proc
to detect this situation and fail.
While testing DAP, we found a situation where a compiler-generated
variable caused the "variables" request to fail -- the variable in
question being an apparent 67-megabyte string.
It seems to me that artificial variables like this aren't interesting
to DAP users, and the gdb CLI omits these as well.
This patch changes DAP to omit these variables, adding a new
gdb.Symbol.is_artificial attribute to make this possible.
PR dap/32090 points out that gdb's DAP "launch" sequencing is
incorrect. The current approach (which is itself a 2nd
implementation...) was based on a misreading of the spec. The spec
has since been clarified here:
https://github.com/microsoft/debug-adapter-protocol/issues/497
The clarification here is that a client is free to send the "launch"
(or "attach") request at any point after the "initialized" event has
been sent by gdb. However, the "launch" does not cause any action to
be taken -- and does not send a response -- until after
"configurationDone" has been seen.
This patch implements this by arranging for the launch and attach
commands to return a DeferredRequest object.
All the tests needed updates. I've also added a new test that checks
that the deferred "launch" request can be cancelled. (Note that the
cancellation is lazy -- it also waits until configurationDone is seen.
This could be fixed, but I was not sure whether it is important to do
so.)
Finally, the "launch" command has a somewhat funny sequencing now.
Simply sending the command and waiting for a response yielded strange
results if the inferior did not stop -- in this case, the repsonse was
never sent. So now, the command is split into two parts, with some
setup being done synchronously (for better error propagation) and the
actual "run" being done async.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32090
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
This adds a new "deferred request" capability to DAP. The idea here
is that if a request returns a DeferredRequest object, then no
response is sent immediately to the client. Instead, the request is
pending until the deferred request is rescheduled.
Some minor refactorings, particularly in cancellation, were needed to
make this work.
There's no use of this in the tree yet -- that is the next patch.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
This patch started as an attempt to fix the comment in
CancellationHandler.cancel, but while working on it I found that the
code could be improved as well.
The current DAP cancellation code only handles the case where work is
done on the gdb thread -- by checking for cancellation in
interruptable_region. This means that if a request is handled
completely in tthe DAP thread, then cancellation will never work.
Now, this isn't a bug per se. DAP doesn't actually require that
cancellation succeed. In fact, I think it can't, because cancellation
is inherently racy.
However, a coming patch will add a sort of "pending" request, and it
would be nice if that were cancellable before any commands are sent to
the gdb thread.
No test in this patch, but one will arrive at the end of the series.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
This refactors the DAP CancellationHandler to be a context manager,
and reorganizes the caller to use this. This is a bit more robust and
also simplifies a subsequent patch in this series.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
This adds a new call_function_later API to DAP. This arranges to run
a function after the current request has completed. This isn't used
yet, but will be at the end of this series.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
This patch changes how delayed events are implemented in DAP. The new
implementation makes it simpler to add a delayed function call, which
will be needed by the final patch in this series.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
Right now, stopAtBeginningOfMainSubprogram is implemented "by hand",
but then later the launch function uses "starti" to implement
stopOnEntry. This patch unifies this code and rewrites it to use
"start" when appropriate.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
In commit 8a61ee551c ("[gdb/symtab] Workaround PR gas/31115"), I applied a
workaround for PR gas/31115 in read_func_scope, fixing test-case
gdb.arch/pr25124.exp.
Recently I noticed that the test-case is failing again.
Fix this by factoring out the workaround into a new function fixup_low_high_pc
and applying it in dwarf2_die_base_address.
While we're at it, do the same in dwarf2_record_block_ranges.
Tested on arm-linux with target boards unix/-marm and unix/-mthumb.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Currently aarch64-linux.xml.in is skipped by update-linux-from-src.sh:
...
$ ./update-linux-from-src.sh ~/upstream/linux-stable.git/
Skipping aarch64-linux.xml.in, no syscall.tbl
...
$
...
and instead we use update-linux.sh.
This works fine, but requires an aarch64 system with recent system headers,
which makes it harder to pick up the latest changes in the linux kernel.
Fix this by updating ./update-linux-from-src.sh to:
- build the linux kernel headers for aarch64
- use update-linux.sh with those headers to generate
aarch64-linux.xml.in.
Regenerating aarch64-linux.xml.in using current trunk of linux-stable gives me
these changes:
...
+ <syscall name="setxattrat" number="463"/>
+ <syscall name="getxattrat" number="464"/>
+ <syscall name="listxattrat" number="465"/>
+ <syscall name="removexattrat" number="466"/>
...
which are the same changes I see for the other architectures.
Note that the first step, building the linux kernel headers is a cross build
and should work on any architecture.
But the second step, update-linux.sh uses plain gcc rather than a cross-gcc,
so there is scope for problems, but we seem to get away with this on
x86_64-linux.
So, while we could constrain this to only generate aarch64-linux.xml.in on
aarch64-linux, I'm leaving this unconstrained.
For aarch64-linux.xml.in, this doesn't matter much to me because I got an
aarch64-linux system.
But I don't have a longaarch system, and the same approach seems to work
there. I'm leaving this for follow-up patch though.
Tested on aarch64-linux and x86_64-linux. Verified with shellcheck.
Commit c8889b9131 ("gdb, gdbserver, gdbsupport: remove some unused
gdb_vecs.h includes") removed gdbsupport/gdb_vecs.h from various
header files. This caused an compile issue for gdb/s390-linux-nat.c
../../binutils-gdb/gdb/s390-linux-nat.c: In member function ‘virtual int s390_linux_nat_target::remove_watchpoint(CORE_ADDR, int, target_hw_bp_type, expression*)’:
../../binutils-gdb/gdb/s390-linux-nat.c:875:11: error: ‘unordered_remove’ was not declared in this scope
875 | unordered_remove (state->watch_areas, ix);
| ^~~~~~~~~~~~~~~~
../../binutils-gdb/gdb/s390-linux-nat.c: In member function ‘virtual int s390_linux_nat_target::remove_hw_breakpoint(gdbarch*, bp_target_info*)’:
../../binutils-gdb/gdb/s390-linux-nat.c:928:11: error: ‘unordered_remove’ was not declared in this scope
928 | unordered_remove (state->break_areas, ix);
| ^~~~~~~~~~~~~~~~
Fix this by including gdbsupport/gdb_vecs.h in gdb/s390-linux-nat.c.
Remove the 'struct' keyword in occurrences of 'struct thread_info'.
This is a code clean-up.
Tested by rebuilding.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
After the commit:
commit 03ad29c86c
Date: Wed Jun 19 11:14:08 2024 +0100
gdb: 'target ...' commands now expect quoted/escaped filenames
it was no longer possible to pass GDB the name of a core file
containing any special characters (white space or quote characters) on
the command line. For example:
$ gdb -c /tmp/core\ file.core
Junk after filename "/tmp/core": file.core
(gdb)
The problem is that the above commit changed the 'target core' command
to expect quoted filenames, so before the above commit a user could
write:
(gdb) target core /tmp/core file.core
[New LWP 2345783]
Core was generated by `./mkcore'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000401111 in ?? ()
(gdb)
But after the above commit the user must write:
(gdb) target core /tmp/core\ file.core
or
(gdb) target core "/tmp/core file.core"
This is part of a move to make GDB's filename argument handling
consistent.
Anyway, the problem with the '-c' command line flag is that it
forwards the filename unmodified through to the 'core-file' command,
which in turn forwards to the 'target core' command.
So when the user, at a shell writes:
$ gdb -c "core file.core"
this arrives in GDB as the unquoted string 'core file.core' (without
the single quotes). GDB then forwards this to the 'core-file'
command as if the user had written this at a GDB prompt:
(gdb) core-file core file.core
Which then fails to parse due to the unquoted white space between
'core' and 'file.core'.
The solution I propose is to escape any special characters in the core
file name passed from the command line before calling 'core-file'
command from main.c.
I've updated the corefile.exp test to include a test for passing a
core file containing a white space character. While I was at it I've
modernised the part of corefile.exp that I was touching.
Make the 'struct breakpoint *' argument 'const' in user_breakpoint_p
and pending_breakpoint_p. And make the 'struct bp_location *'
argument 'const' in bl_address_is_meaningful.
There should be no user visible changes after this commit.
.cfi directives only support the use of register numbers and not
register names or aliases.
This commit adds support for 4 formats, for example:
.cfi_offset r1, 8
.cfi_offset ra, 8
.cfi_offset $r1,8
.cfi_offset $ra,8
The above .cfi directives are equivalent and all represent dwarf
register number 1.
Display register aliases as specified in the psABI during disassembly.
In the spirit of encapsulation, I'm looking to remove the need for
external code to access the "ptid -> thread" map of process_info, making
it an internal implementation detail. The only remaining use is in
function clear_inferiors, and it led me down this rabbit hole:
- clear_inferiors is really only used by the Windows port and doesn't
really make sense in the grand scheme of things, I think (when would
you want to remove all threads of all processes, without removing
those processes?)
- ok, so let's remove clear_inferiors and inline the code where it's
called, in function win32_clear_inferiors
- the Windows port does not support multi-process, so it's not really
necessary to loop over all processes like this:
for_each_process ([] (process_info *process)
{
process->thread_list ().clear ();
process->thread_map ().clear ();
});
We could just do:
current_process ()->thread_list ().clear ();
current_process ()->thread_map ().clear ();
(or pass down the process from the caller, but it's not important
right now)
- so, the code that we've inlined in win32_clear_inferiors does 3
things:
- clear the process' thread list and map (which deletes the
thread_info objects)
- clear the dll list, which just basically frees some objects
- switch to no current process / no current thread
- let's now look at where this win32_clear_inferiors function is used:
- in win32_process_target::kill, where the process is removed just
after
- in win32_process_target::detach, where the process is removed
just after
- in win32_process_target::wait, when handling a process exit.
After this returns, we could be in handle_target_event (if async)
or resume (if sync), both in `server.cc`. In both of these
cases, target_mourn_inferior gets called, we end up in
win32_process_target::mourn, which removes the process
- in all 3 cases above, we end up removing the process, which takes
care of the 3 actions listed above:
- the thread list and map get cleared when the process gets
destroyed
- same with the dll list
- remove_process switches to no current process / current thread
if the process being removed is the current one
- I conclude that it's probably unnecessary to do the cleanup in
win32_clear_inferiors, because it's going to get done right after
anyway.
Therefore, this patch does:
- remove clear_inferiors, remove the call in win32_clear_inferiors
- remove clear_dlls, which is now unused
- remove process_info::thread_map, which is now unused
- rename win32_clear_inferiors to win32_clear_process, which seems more
accurate
win32_clear_inferiors also does:
for_each_thread (delete_thread_info);
which also makes sure to delete all threads, but it also deletes the
Windows private data object (windows_thread_info), so I'll leave this
one there for now. But if we could make the thread private data
destruction automatic, on thread destruction, it could be removed, I
think.
There should be no user-visible change with this patch. Of course,
operations don't happen in the same order as before, so there might be
some important detail I'm missing. I'm only able to build-test this, if
someone could give it a test run on Windows, it would be appreciated.
Change-Id: I4a560affe763a2c965a97754cc02f3083dbe6fbf
The recent commit <HASH> moved an initialization of an objfile_holder in
syms_from_objfile_1 much earlier in the function, to better deal with
when GDB is unable to read the objfile format.
However, there is an early exit from syms_from_objfile_1 when the
objfile can be understood, but has no symbols. That was not releasing
the objfile_holder, so the objfile was being unlinked from the program
space, but the process of reading the objfile was being continued,
leading to use-after-frees flagged by the Address Sanitizer.
This commit fixes that UAF by making the objfile_holder release the
objfile right before the early exit.
This commit also changes the test gdb.base/dump.exp since that was the
original test that flagged the UAF, but at the end of the test the
generated files were being deleted, meaning we couldn't redo the test
manually after the fact. That final deletion was removed
Reported-by: Simon Marchi <simark@simark.ca>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Currently we have duplicate code for each place where
windows_thread_info::context is touched, since for WOW64 processes
it has to do the equivalent with wow64_context instead.
For example this code...:
#ifdef __x86_64__
if (windows_process.wow64_process)
{
th->wow64_context.ContextFlags = WOW64_CONTEXT_ALL;
CHECK (Wow64GetThreadContext (th->h, &th->wow64_context));
...
}
else
#endif
{
th->context.ContextFlags = CONTEXT_DEBUGGER_DR;
CHECK (GetThreadContext (th->h, &th->context));
...
}
...changes to look like this instead:
windows_process.with_context (th, [&] (auto *context)
{
context->ContextFlags = WindowsContext<decltype(context)>::all;
CHECK (get_thread_context (th->h, context));
...
}
The actual choice if context or wow64_context are used, is handled by
this new function in windows_process_info:
template<typename Function>
auto with_context (windows_thread_info *th, Function function)
{
#ifdef __x86_64__
if (wow64_process)
return function (th != nullptr ? th->wow64_context : nullptr);
else
#endif
return function (th != nullptr ? th->context : nullptr);
}
The other parts to make this work are the templated WindowsContext class
which give the appropriate ContextFlags for both types.
And there are also overloaded helper functions, like in the case of
get_thread_context here, call either GetThreadContext or
Wow64GetThreadContext.
According git log --stat, this results in 120 lines less code.
Approved-By: Tom Tromey <tom@tromey.com>
Update expected outputs in testsuite/pr26936.sh to match the assembler
outputs changed by:
a96a8b7367 is the first bad commit
commit a96a8b7367 (HEAD)
Author: Jan Beulich <jbeulich@suse.com>
Date: Mon Dec 2 09:38:47 2024 +0100
x86: always set ISA_1_BASELINE property for 64-bit objects
PR gold/32422
* testsuite/pr26936.sh: Updated.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
For default linker script, if a symbol's value outsides the bounds of the
defined section, then it may cross the data segment alignment, so we should
reserve more size about MAXPAGESIZE and COMMONPAGESIZE when doing gp
relaxations. Otherwise we may meet the truncated errors since the data
segment alignment might move the section forward.
bfd/
PR 27566
* elfnn-riscv.c (_bfd_riscv_relax_lui): Consider MAXPAGESIZE and
COMMONPAGESIZE if the symbol's value outsides the bounds of the
defined section.
(_bfd_riscv_relax_pc): Likewise.
ld/
PR 27566
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
* testsuite/ld-riscv-elf/relax-data-segment-align*: New testcase
for pr27566. Without this patch, the rv32 binutils will meet
truncated errors for this testcase.
Fix this:
gdbserver/win32-low.cc: In function ‘void child_delete_thread(DWORD, DWORD)’:
gdbserver/win32-low.cc:192:7: error: ‘all_threads’ was not declared in this scope; did you mean ‘using_threads’?
192 | if (all_threads.size () == 1)
| ^~~~~~~~~~~
| using_threads
Commit 9f77b3aa0b ("gdbserver: change 'all_processes' and
'all_threads' list type") changed the type of `all_thread` to an
intrusive_list, without changing this particular use, which broke the
build because an intrusive_list doesn't know its size, so it doesn't
have a `size()` method. The subsequent commit removed `all_threads`,
leading to the error above.
Fix it by using the number of threads of the concerned process instead.
My rationale: as far as I know, GDBserver on Windows only supports one
process at a time, so there's no need to iterate over all processes. If
we made GDBserver for Windows support multiple processes, my intuition
is that we'd want this check to use the number of threads of the
concerned process, not the number of threads overall.
Add the method `process_info::thread_count`, to get the number of
threads of the process.
I'm not really sure what this check is for in the first place, Hannes
Domani said that this check didn't seem to trigger on Windows 7 and 11.
Perhaps it was necessary before.
Change-Id: I84d6226532b887d99248cf3be90f5065fb7a074a
Tested-By: Hannes Domani <ssbssa@yahoo.de>
In this patch, we will support AVX10.2 satcvt instructions. All of them
are new instruction forms. In current documentation, it is still
VCVTTNEBF162I[,U]BS, but it will change to VCVTTBF162I[,U]BS eventually.
In table part, we used temporary <sign> iterator to reduce redundancy.
It definitely could be done for legacy cvt insns, but it is out of this
patch's scope.
gas/ChangeLog:
* testsuite/gas/i386/i386.exp: Add AVX10.2 tests.
* testsuite/gas/i386/x86-64.exp: Ditto.
* testsuite/gas/i386/avx10_2-512-satcvt-intel.d: New test.
* testsuite/gas/i386/avx10_2-512-satcvt.d: Ditto.
* testsuite/gas/i386/avx10_2-512-satcvt.s: Ditto.
* testsuite/gas/i386/avx10_2-256-satcvt-intel.d: Ditto.
* testsuite/gas/i386/avx10_2-256-satcvt.d: Ditto.
* testsuite/gas/i386/avx10_2-256-satcvt.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-512-satcvt-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-512-satcvt.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-512-satcvt.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-satcvt-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-satcvt.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-satcvt.s: Ditto.
opcodes/ChangeLog:
* i386-dis-evex-prefix.h: Add PREFIX_EVEX_MAP5_68, PREFIX_EVEX_MAP5_69,
PREFIX_EVEX_MAP5_6A, PREFIX_EVEX_MAP5_6B, PREFIX_EVEX_MAP5_6C,
PREFIX_EVEX_MAP5_6D.
* i386-dis-evex-w.h: Add EVEX_W_MAP5_6C_P_0, EVEX_W_MAP5_6C_P_2,
EVEX_W_MAP5_6D_P_0, EVEX_W_MAP5_6D_P_2.
* i386-dis-evex.h (prefix_table): Add PREFIX_EVEX_MAP5_68,
* PREFIX_EVEX_MAP5_69, PREFIX_EVEX_MAP5_6A, PREFIX_EVEX_MAP5_6B.
* i386-dis.c: (PREFIX_EVEX_MAP5_68): New.
(PREFIX_EVEX_MAP5_69): Ditto.
(PREFIX_EVEX_MAP5_6A): Ditto.
(PREFIX_EVEX_MAP5_6B): Ditto.
(PREFIX_EVEX_MAP5_6C): Ditto.
(PREFIX_EVEX_MAP5_6D): Ditto.
(EVEX_MAP5_6C_P_0): Ditto.
(EVEX_MAP5_6C_P_2): Ditto.
(EVEX_MAP5_6D_P_0): Ditto.
(EVEX_MAP5_6D_P_2): Ditto.
* i386-opc.tbl: Add AVX10.2 instructions.
* i386-mnem.h: Regenerated.
* i386-tbl.h: Ditto.
Co-authored-by: Zewei Mo <zewei.mo@intel.com>
Co-authored-by: Haochen Jiang <haochen.jiang@intel.com>
Co-authored-by: Levy Hsu <admin@levyhsu.com>
