Don't do an out-of-range check for the operands, even
temporarily. Setting the operand pointer to NULL will help catch
errors when accessing non-operands, too.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
At least three files (asm/assemble.c, disasm/disasm.c, and
x86/insns.pl) depend on the bytecode defintions. It makes a lot more
sense for them to live in an explicit documentation file in the x86/
directory.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
"LOCK XCHG reg,mem" would issue a warning for being unlockable, which
is incorrect. In this case the RM encoding is simply an alias for the
MR encoding. Add a "LOCK1" bit to deal with that.
However, XCHG is *always* locked, so create a new warning to
explicitly flag a user-specified LOCK XCHG; default off.
Consider optimizing that prefix away in the future, but for now, let's
stick to the user-requested code sequence.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Some target environments may have specific restrictions on what kinds
of relocations are possible or allowed. Allow users to opt-in to
specific warnings as to the relocations they cannot support.
Requested-by: C. Masloch <pushbx@ulukai.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Document CPU LATEVEX and the associated prefixes; add CPU EVEX and CPU
VEX flags to further control encodings.
Fix the error message for invalid encodings due to flags.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
For VEX instructions created *after* the corresponding EVEX
instructions, we need the user to either explicitly declare them {vex}
or specifying "cpu latevex".
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Instead of handling conditional instructions ad hoc, generate
individual instruction patterns as normal. This simplifies the code
and makes CMPccXADD support simpler (otherwise it would be necessary
to hack in the handling of a condition code in the middle of an
instruction.)
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The FP16 patch had a case of bit overlap. Clean up the handling of
broadcast flags a little in the process.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Warnings with explicit [rel] would pretty much *always* warn after
checkin f4e7a636a85bab02e7ac0067c5c58768779900a0. Fix this.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add support for AVX512-FP16 instructions and the associated
handling. Allow "mapN" syntax as well as "mN" syntax to match the
documentation.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The size calculation done in len_extops() (called by insn_size()) for
EOT_DB_RESERVE (i.e. uninitialized storage "?" token) does not take
into account the element size (e->elem), thus calculating a wrong
size for any Dx larger than DB (DW, DQ, etc).
The bug is silent, but it makes NASM error out if a "Dx ?" (larger
than DB) is followed by any label because the label offset gets
mismatched in the final code generation stage:
$ cat test.asm
[section .bss]
DW ?
x:
$ nasm test.asm
test.asm:3: error: label `x' changed during code generation [-w+error=label-redef-late]
See also: https://stackoverflow.com/q/70012188/3889449
Signed-off-by: Marco Bonelli <marco@mebeim.net>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
In commit 2469b8b6 we occasionally bring the ability
to read unitialized memory due to refactoring. Fix it
doing needed test inside the function and setting up
an error message if needed.
Side note: passing 7 arguments into the function means
we have to decompose this helper somehow, such number
of arguments is a way over the top.
Bugzilla: https://bugzilla.nasm.us/show_bug.cgi?id=3392751
Reported-by: Marco <mvanotti@protonmail.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Add a {rex} prefix to force REX encoding (typically a redundant 40h
prefix).
For prefix parsing, we can use t_inttwo to encode the prefix slot
number.
Give more verbose error messages for encoding mismatches.
NASM 2.15.04
Conflicts:
asm/listing.h
asm/pptok.pl
asm/preproc.c
version
This doesn't pass travis test 3392711, which is using an extremely odd
construct of %?? in the middle of an argument sequence for an smacro
while not being in a macro itself, and expecting it to expand to the
macro name. This seems to *really* confuse the master branch.
Resolve this later...
BNDMK, BNDLDX, and BNDSTX are split-SIB (MIB) instructions, but do
*not* require a SIB encoding. However, TILELOAD* and TILESTORE* *do*
require a SIB in all cases. Split the MIB flag into MIB (split
address) and SIB (SIB required) flags.
This fixes travis test mpx.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
When using the LEA instruction with immediate syntax instead of memory
operand syntax, the IP_REL flag will not have made it into the operand
type. Make it do so.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
With -Lb, it is possible that we don't have a filename for the current
code expansion. In that case, suppress calling dfmt->linenum as some
debug backends *really* aren't equipped to handle that case.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed and unsigned are really two flags; might as well allow this
field to contain additional flags.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
If the segment number changes, we also need to invoke dfmt->linenum(),
as a .nolist macro may end up emitting to more than one section.
This also adds the source location explicitly to the output data
structure; the cost for that is minimal, and will enable a more
sophisticated debug backend to receive the entire data structure in
the future.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Don't pass a NULL filename to dfmt->linenum even if -Lb is in use; it
confuses the heck out of some debug backends.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
We need the exact match in the rbtree for the current section. An
approximate match is not acceptable.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Collect macro call/nesting information for the benefit of the debug
back end. So far, the only backend for which this is provided is the
debug back end, to show what information is present.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The a64 instruction patterns would incorrectly force REX to zero at a
point where REX prefixes have already been assigned. This is not only
incorrect in case of instructions which can use high registers, but it
causes an assertion failure. It happened to work for J*CXZ and LOOP*.
Reported-by: Philip Lantz <philip.lantz@intel.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Add support for complex data (Dx) statement expressions involving both
initialized and uninitialized data. In addition, we have support for
overriding the size of each element on an individual item and/or list
basis.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Ponderance: if data->bits < globalbits, should we actually use
OUT_UNSIGNED rather than OUT_WRAP here?
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
If the address we are using is >= the size of the instruction, then
don't complain on overflow as we can wrap around the top and bottom of
the address space just fine.
Alternatively we could downgrade it to OUT_WRAP in that case.
Reported-by: C. Masloch <pushbx@38.de>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The memory operand size of LEA doesn't matter in any way as it isn't
"real memory". Add an ANYSIZE option to ignore sizes entirely.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
"instruction never implemented and removed from the target CPU"
... doesn't really make sense, so change it to ...
"instruction never implemented and invalid on the target CPU"
(still may seen redundant, but it is to distingush it from "and is a
noop on...")
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Distinguish instructions which have once been valid (OBSOLETE) from
those that never saw the light of day (NEVER). Futhermore, flag
instructions which devolve to an architectural noop from those with
undefined behavior and possibly recycled opcodes.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Just becase one is compiling for an old CPU doesn't mean one wants to
use obsolete instructions that would not be forward compatible. Rename
the "obsolete" warning to "obsolete-removed" and create a new
"obsolete-valid" warning to go with it (-w[+-]obsolete controls both
options, as usual.)
Suggested-by: C. Masloch <pushbx@38.de>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
For constructs like TIMES xx RESB yy merge the TIMES and RESB and feed
a single reservation to the backend; this can (obviously) be
dramatically faster.
Add byte count in listings for <incbin> and repeat count to <rept>; to
make them more reasonable in length shorten to <bin ...> and <rep ...>
respectively, and don't require leading zeroes in bin/rep/res count.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Print a warning if one tries to assemble an obsolete instruction,
unless there is an exact match for the CPU directive.
For example:
CPU 386
POP CS ; Warning - obsolete instruction
CPU 8086
POP CS ; No warning
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Zeroing reserved space in a progbits section really should be a
separate warning class, so it can be controlled independently.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
"compiler.h" already includes a bunch of common include files. There
is absolutely no reason to duplicate them in individual files, and in
fact it robs us of central control of how these files are used.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
There is absolutely no reason not to include <string.h> globally, and
with the inline function for mempcpy() we need it there anyway.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
