For the versions of VCMPxx which already embed their condition code,
we do not want an extra immediate argument.
Todo: fix bytecode compiler to complain more about these.
Guess what, SEH again, but in Win64 context, which is completely
different matter from Win32. At lowest level this one boils down to
putting so called imagerel references, or in practical terms
relocations of type ADDR32NB, 0x0003, into .pdata and .xdata
segments. Two possibilities. 1. implement say 'wrt ..imagerel' or 'wrt
..imagebase'. 2. silently enforce ADDR32NB relocations in .pdata and
.xdata segments.
This is basically not a bug report, but a feature request.
It's desired to be able to link .obj modules compiled with 'nasm -f
win32' with Microsoft 'link /safeseh'. As well as to register symbols
(commonly subroutine's entry points or even external symbols) as "safe
handlers." In order to achieve this, several points are required.
First of all, object module has to have absolute symbol named @feat.00
with value of 1. This can actually be achived by adding 'absolute 1'
and '@feat.00:' to source code, but it's desirable that it's
autogenerated for win32 modules.
Handler registration is essentially symbol's *index* in current
module's symbol table in .sxdata, segment with 0x200 segment flags, an
"info" segment. It's also essential that symbol has type 0x20 (see
below). All this is depicted in following framgents of 'objdump -xD'
output:
Sections:
Idx Name Size VMA LMA File off Algn
0 .sxdata 00000004 00000000 00000000 0000003c 2**2
CONTENTS, READONLY, DEBUGGING
SYMBOL TABLE:
...
[ 5](sec -1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x00000001 @feat.00
[ 6](sec 0)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x00000000 _handler
...
<.sxdata>
0: 06 00 00 00
Note [6] and (ty 20) in _handle line in SYMBOL TABLE. "06 00 00 00" in
.sxdata is little-endian 6, _handler's index. This is what makes up
"registration." It's impossible to achieve this with current nasm
facilities and it's probably appropriate to introduce a directive for
it, 'safeseh _handler' is probably most natural choice.
Normally, contexts aren't used with a large number of macros, but in
case someone does, do use hash tables for those as well. This
simplifies the code somewhat, since *all* handling of macros is now
done via hash tables.
Future note: consider if it wouldn't be better to allow struct
hash_table to be allocated by the caller, instead of being allocated
by the hash table routine.
The disassembler code gets cleaner if we do *not* separate out the
conditional instructions; instead, rely on the fact that the
conditionals are always at the end and use FIRST_COND_OPCODE as a
barrier.
We can use the new VEX prefixes to select into a large table of new
opcode spaces. Since the table is (currently) sparse, add logic so we
don't end up producing tons of empty tables for no good reason.
This is also necessary since VEX is likely to reuse opcode bytes that
would appear as prefixes at some point, which would cause conflicts
with the regular tables.
All singleton registers need to be displayable from register flags
alone!
When using the new 0360..0363 codes, make sure we appropriate avoid
displaying the legacy use of the prefixes.
Fix buffer overflow in preproc.c due to an incorrect test. In the
code:
for (r = p, s = ourcopy; *r; r++) {
if (r >= p+MAX_KEYWORD)
return tokval->t_type = TOKEN_ID; /* Not a keyword */
*s++ = tolower(*r);
}
*s = '\0';
... the test really needs to be >= since for the pass where there are
equal:
a) a nonzero byte means we have > MAX_KEYWORD characters, and
b) s = ourcopy+MAX_KEYWORD; but if the test doesn't trigger,
we can write one more character *plus* the null byte, overflowing
ourcopy.
Support is4 bytes without meaningful information in the bottom bits.
This is equivalent to /is4=0 for the assembler, but makes the bottom
bits don't care for the disassembler.
Make our way through the AVX instructions: conversions.
This is all I have time for now... hopefully this can service as a
generous source of examples.
Accept the gas mnemonics "ud2a" and "ud2b" for the instructions we
call ud2 and ud1 respectively, and Intel call ud2 and undocumented :)
Also, 0F FF is ud0 regardless of prefixes, at least as far as we know.
