Two fixes:
1. Optimization of [bx+0xFFFF] etc
0xFFFF is an sbyte under 16-bit semantics,
so make sure to check it right.
2. Don't optimize displacements in -O0
Displacements that fit into an sbyte or
can be removed should *not* be optimized in -O0.
Implicit zero displacements are still optimized, e.g.:
[eax] -> 0 bit displacement, [ebp] -> 8 bit displacement.
However explicit displacements are not optimized:
[eax+0] -> 32 bit displacement, [ebp+0] -> 32 bit displacement.
Because #2 breaks compatibility with 0.98,
I introduced a new optimization level: -OL, legacy.
Under particular circumstances %strlen may cause SIGSEG. A typical
example is %strlen with nonexistent macro argument.
[ Testcase test/strlen.asm ]
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Allow non-identifier characters in the name of environment variables,
by surrounding them with string quotes (subject to ordinary
string-quoting rules.)
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
We still miss Chuck, but I don't think we can really say anymore we're
doing this particular release in his memory.
Requiescat in pace, our friend.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Make -Ox the default; it's the optimization level expected by most
users, and it is clearly still causing confusion that it has to be
specified manually.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add %ifenv to test for the presence of an environment variable. The
environment variable can, but does not have to be, prefixed with %!.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Revert to issuing a nonfatal error (it makes no sense to make it a
fatal error, but it probably makes sense for it to be an error instead
of a warning, especially since a lot of prior versions would crash and
apparently noone noticed.) We might have to revisit this based on
user requirements, and/or provide a method for the user to detect an
existing environment variable (%ifenv?).
Issue a better error message, indicating the nature of the failure.
Simplify the code by just updating the string in "p".
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Frank suggested to just print out an error if environment
variable is not there. Agreed.
Suggested-by: Frank Kotler <fbkotler@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Frank reported we hit NULL dereference on nonexistent
environment variables. Fix it by leaving empty string
in text field of such token and yielding warning.
Reported-by: Frank Kotler <fbkotler@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
At moment of calling the nasm_skip_string the string pointer
is already incremented which makes tokenize fail on correct
indirect strings.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
The commits
20a94ad7fe41c82f77fb670abb68f0de40d2b3e5
29c96651de1c43e59b7db58a4f06ff21dc854125
13dbfad76b4d3dbf27ef41761873584c6bd9fd7f
6f5f7ef417c37c154d10c2b3813808ad3fa65fd7
ddd08c3cccb4b68ecdb24d7a92eab6b2b82e8c68
seems to do the tricks we need. Eventually
get rid of commented "case".
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
In case if there is a whitespace before
'paste' token we may reach NULL dereference
in strlen since paste_head will point to
TOK_WHITESPACE. Fix it.
[mainstream adabc1576b957fc7d929d2c7e749b4f45f7293aa]
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
In case if there is a whitespace before
'paste' token we may reach NULL dereference
in strlen since paste_head will point to
TOK_WHITESPACE. Fix it.
[test: paste.asm]
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Add FXSAVE64 and FXRSTOR64; drop the np prefix on 0F AE instructions:
none of the rest of the 0F AE instructions have them, and there are no
conflicts.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
FUTURE is a CPU level flag, and cannot be combined with X64 (which is
shorthand for X86_64,LONG). Also, make sure we add LONG annotations
to everything that is 64-bit mode only.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add the RD*SBASE, WR*SBASE and RDRAND instructions from version 7 of
the AVX specification, Intel document 319433-007.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
In commit 55ae12052cd1 we occasionally broke byte ordering. Fix it.
Note that current stable version 2.08.01 is not affected by this bug.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
inslist.src is an intermediate file, it should be in "make clean"
rather than "make spotless"; otherwise it ends up in the xdoc tarball.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
PUSH imm64 confuses ones who is trying to find this instruction in
processor programming manuals.
Actually it was introduced in a sake of "push `size' imm" consistency.
In other words -- to allow users to state "PUSH qword imm32" in 64bit code,
though on byte level (ie generated) code it still has a correct and valid
sign-extended "PUSH imm32" instruction.
To get rid of this ambiguie bite we make explicit "PUSH imm32"
being valid in 64bit code. This also makes "PUSH dword imm32"
valid in 64bit code as well.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
We need mac->nparam being explicictly int'fied otherwise
compiler issue a warning. Note that we might have been
using unsigned int but it would break an ability to pass
negative indices.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
