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>
Michael proposed to run
| sed -i -e '/^.PHONY: all/s/$/ test/' Makefile.in
since we have test/ directory. Good idea.
Reported-by: Michael Sterrett
Patch-by: Michael Sterrett
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
As being pointed by "matching braces" topic on
[ http://forum.nasm.us/index.php?topic=905.0 ]
we don't issue warning on missed match for "{"
brace opened.
Strictly speaking we should issue error instead and
force user to fix asm source code but since it's
here for a long time already -- lets be "admissive".
Reported-by: Klod
CC: Frank Kotler <fbkotler@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
We could have accessed malloc'ed data on external symbols
in obj and ieee output formats. Fix it by using nasm_zalloc.
Reported-by: Jiri Malak
Patch-by: Jiri Malak
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
If we're to print inside %rep block we should find
out which %macro it belongs.
Reported-by: Rob Neff
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
As being pointed by "matching braces" topic on
[ http://forum.nasm.us/index.php?topic=905.0 ]
we don't issue warning on missed match for "{"
brace opened.
Strictly speaking we should issue error instead and
force user to fix asm source code but since it's
here for a long time already -- lets be "admissive".
Reported-by: Klod
CC: Frank Kotler <fbkotler@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
In mmacro params head TOK_NUM should be concat'ed with
tail TOK_NUM only, otherwise the weird construction like
%define id1 1
%define idid1 2
%define TOK_NUM 1
%define TOK_ID id
%macro m 2
mov eax, 1%1id%2 ; this expands to 1idid1
; where idid1 expands to 2
; and then to 12
%endmacro
m TOK_ID, TOK_NUM
issue error.
N.B. I've checked nasm-0.98.39 and it compiles this macro
perfectly well, for the record.
Reported-by: nasm64developer@users.sf.net
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
We could have accessed malloc'ed data on external symbols
in obj and ieee output formats. Fix it by using nasm_zalloc.
Reported-by: Jiri Malak
Patch-by: Jiri Malak
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
During nasm-2.06 development we broke the rules for
concatenation of preprocessor tokens (d784a083a3).
The former candidates for concatenation were (in terms of RE)
expand_smacro
[(TOK_ID|TOK_PREPROC_ID)][(TOK_ID|TOK_PREPROC_ID|TOK_NUMBER)]
expand_mmac_params
[(TOK_ID|TOK_NUMBER|TOK_FLOAT)][(TOK_ID|TOK_NUMBER|TOK_FLOAT|TOK_OTHER)]
[ nb: review commits ec88c1beac , 20a94ad7fe and 984279b1dd if
you going to change this one ]
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
