In fact it was written as
MOVAPS xmmreg,xmmreg \360\2\x0F\x28\110 KATMAI,SSE
MOVAPS xmmreg,xmmreg \360\2\x0F\x29\101 KATMAI,SSE
in first place
MOVUPS xmmreg,xmmreg \360\2\x0F\x10\110 KATMAI,SSE
MOVUPS xmmreg,xmmreg \360\2\x0F\x11\101 KATMAI,SSE
and for example x28 stands for xmmrm128,xmmreg and
x1 for xmmrm128,xmmreg.
TODO: Inspect and fix WILLAMETTE instructions.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Some important fixes:
- Fix incorrect labels offset for VEX intructions
- Eliminate bogus warning on implicit operand size override.
- %if term could not handle 64 bit numbers.
- The COFF backend was limiting relocations number to 16 bits even if
in real there were a way more relocations.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
The implicit operand size override code didn't set the operand size
prefix, which confused the size calculation code for the range check.
The BITS 64 operand size calculation is still off, but "fixing" it by
making it 32-bit unless REX.W is set breaks PUSH and maybe others.
reloc_value returns 64bit numbers but we strip it down
to 'int' which causes problems if the former value is
big enough to overflow 'int'. Fix it.
[ BR3104312 ]
Reported-by: Christian Masloch
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
The backport of
4db724fdd7359b63f89701102ee8e62672af7379
so coff output target to be able to handle
massive relocations.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
calcsize() had the wrong criterion for when C5 prefixes are permitted
(REX.R is permitted, REX.X is forbidden.) assemble() had the right
test already. This caused symbol value errors.
While being debugging some nifty problem I found
that it might be useful to produce a full dump of
tokens, in particular text of tokens.
For this reason dump_token is here just to not loose
it. It doesn't affect normal build procedure since it
requires a special -DNASM_TRACE to be passed to the
compiler. Which of course we don't in a regular
compilations.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
If not all members of structure being allocated from
heap get initialized we better to use nasm_zalloc instead
of nasm_malloc.
For example inc gets allocated in do_directive being parially
initialized and we erroniously get mmac_depth set to some
crappy value leading to SIGSEV in result.
[ http://forum.nasm.us/index.php?topic=921.msg3257#msg3257 ]
nb: I've cleaned verror from tab/space mess while were at it
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
The implicit operand size override code didn't set the operand size
prefix, which confused the size calculation code for the range check.
The BITS 64 operand size calculation is still off, but "fixing" it by
making it 32-bit unless REX.W is set breaks PUSH and maybe others.
reloc_value returns 64bit numbers but we strip it down
to 'int' which causes problems if the former value is
big enough to overflow 'int'. Fix it.
[ BR3104312 ]
Reported-by: Christian Masloch
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
In case if relocations number exceed 16bit values
we have to hande such case by a special way, as described
in COFF specification.
"IMAGE_SCN_LNK_NRELOC_OVFL indicates that the count of
relocations for the section exceeds the 16 bits that are
reserved for it in the section header. If the bit is set
and the NumberOfRelocations field in the section header
is 0xffff, the actual relocation count is stored in the
32-bit VirtualAddress field of the first relocation. It
is an error if IMAGE_SCN_LNK_NRELOC_OVFL is set and
there are fewer than 0xffff relocations in the section."
[ BR3092924 ]
Reported-by: Robert Yates
Investigated-by: nasm64developer
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Actually it's temporary action. We have to support more
relocations then that but it requires some more code rework.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
