If we have external dependencies, we need Makefile.dep to exist;
this forces make to invoke the Makefile.dep target if this file is
missing.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
There is no point to run config.status --recheck just because
we have changed Makefile.in. Just run config.status.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
There is no reason to include both nasmdoc.pdf.xz and nasmdoc.pdf. For
the -xdoc file, the one with minimal dependencies is the proper one.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Building NASM from scratch needs perl.
.pdf.xz is now build by the standard NASM Makefile.in, so don't
do it again (it causes failures.)
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
A trailing comma at the end of an mmacro call is an empty
argument, and so we can't terminate the argument-processing loop. The
only case where skip_white() returning NULL where we are allowed to
terminate the loop is in the case of nparams == 0, i.e. the macro call
has no arguments at all.
Reported-by: gabriele balducci <balducci@units.it>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Properly format the error messages when we print them (oops!)
The errhold_stack should be empty after each pass. It may even be
worthwhile to make sure it is empty after each *line*, but do this
for now.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
We must not call nasm_error_hold_push() twice... the obvious
leak of the error stack caused all kinds of errors to be suppressed.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Don't issue smacro expansion warnings until we are sure we are
actually *done* with the smacro expansion. The last pass of
expand_smacro_noreset() gets to commit warnings.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
warning_alias[0] is "all". It is represented in the loop by
value == NULL; WARN_IDX_ALL does not have an entry in warning_state[]
and so trying to poke it is an error.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Fix use of uninitialized variable. This most likely is just an
issue while running at debug level >= 3, but it's still wrong.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
We need the instruction table to contain the correct information for
both the reg and the rm field in the various modes.
Reported-by: <fasdfqwer@mail.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Set an expression descent limit to 8192, which is more reasonable to
expect to work on most platforms. Furthermore, if getrlimit() exists,
then try to use it to see if we need to further limit the size.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
If an include file exists, but cannot be opened, that is still a
critical error.
However, downgrade this from a fatal to a nonfatal error. There really
isn't any reason to stop cold here.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
If the rest of the line is consumed, we may never see tafter, so we
have to test for end of line at line 5412. We already do at 5397, so
it clearly should have been there all along.
Reported-by: <puppet@zju.edu.cn>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Don't set "defining" until the macro definition is successfully parsed
and we know for sure that we are going to define the macro.
Together with:
a762cd4e54 BR 3392668: preproc: test for macro in TOK_LOCAL_SYMBOL
... this addresses BR 3392668.
Reported-by: <puppet@zju.edu.cn>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
TOK_LOCAL_SYMBOL is only applicable inside a macro; otherwise error
out just like we do for TOK_MMACRO_PARAM.
This *partially* addresses BR 3392668.
Reported-by: <puppet@zju.edu.cn>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Significantly improve the portability/reliability of a general
make command. Build a .pdf.xz version of the documentation,
using an uncompressed pdf as basis.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The two VPSH{R|L}DV* instructions had the wrong opcode.
Reported-by: Henrik Gramner <herik@gramner.com>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392607
Signed-off-by: Henrik Gramner <henrik@gramner.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
The binary mode has no difference from text mode in
POSIX-compliant operating systems. The two modes are
distinguishable from each other on Windows, and perhaps
on other systems as well.
The binary stream has scalability and other advantages.
Windows treats the standard input stream as text mode by
default. So the code changes it to binary mode.
Also, add a helper function, nasm_set_binary_mode(),
that is OS-agnostic, in the library.
Reported-by: Didier Stevens <didier.stevens@gmail.com>
Suggested-by: Didier Stevens <didier.stevens@gmail.com>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392649
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
The section information delivered to the debug output has an index of the
section table. The index should be different from the total number of
sections at the moment, the returned value from add_sectname(). So, fix the
value.
Fixes: b2004511dd ("ELF: handle more than 32,633 sections")
Reported-by: C. Masloch <pushbx@ulukai.org>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392654
Reported-by: <mae.bdf@outlook.com>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392661
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Determining whether we should warn on defining a single-line macro, with a
name and a certain number of parameters, call a helper function,
smacro_defined(). It does not always return the address of the definition
structure.
Fix the code to be cautiously accessing the definition structure.
Fixes: e91f5cc132 ("preproc: fix %undef of macro aliases, and add
%ifdefalias")
Reported-by: Dale Curtis <dalecurtis@chromium.org>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392659
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Mistreating the macro-parameter, just equivalent to the given
argument number, leads to casting an unnecessary error. Fix to
assemble the conditional code correctly.
Fixes: de7acc3a46 ("preproc: defer %00, %? and %??
expansion for nested macros, cleanups")
Reported-by: C. Masloch <pushbx@ulukai.org>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392660
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
The code looked to be unintentionally always nullifying the
token pointer at first place in handling those macro-parameters.
Remove it to avoid segfault.
Fixes: de7acc3a46 ("preproc: defer %00, %? and %??
expansion for nested macros, cleanups")
Reported-by: C. Masloch <pushbx@ulukai.org>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392640
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Add the test code into the existing xdefine testing.
Suggested-by: C. Masloch <pushbx@ulukai.org>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392630
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
The code used to stuck in going through whitespace tokens.
Fix to increment towards on the next in the loop.
Reported-by: C. Masloch <pushbx@ulukai.org>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392630
Suggested-by: C. Masloch <pushbx@ulukai.org>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
There are many similar preprocessor loop cases but located
on each bug-report basis. While it looks to be better to
consolidate them together, add one more test case like what
was done before.
Suggested-by: C. Masloch <pushbx@ulukai.org>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392626
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
The code has been fixed to print the corresponding line
numbers of %rep blocks correctly, but only for the first
iteration. For the subsequent iterations, the current line
number on the expansion needs to be explicitly reset again.
Fixes: ab6f831955 ("listing: when listing lines in macros
and rep blocks, show the actual line")
Reported-by: C. Masloch <pushbx@ulukai.org>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392626
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
The two VPSH{R|L}DV* instructions had the wrong opcode.
Reported-by: Henrik Gramner <herik@gramner.com>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392607
Signed-off-by: Henrik Gramner <henrik@gramner.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
The binary mode has no difference from text mode in
POSIX-compliant operating systems. The two modes are
distinguishable from each other on Windows, and perhaps
on other systems as well.
The binary stream has scalability and other advantages.
Windows treats the standard input stream as text mode by
default. So the code changes it to binary mode.
Also, add a helper function, nasm_set_binary_mode(),
that is OS-agnostic, in the library.
Reported-by: Didier Stevens <didier.stevens@gmail.com>
Suggested-by: Didier Stevens <didier.stevens@gmail.com>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392649
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
The code looked to be unintentionally always nullifying the
token pointer at first place in handling those macro-parameters.
Remove it to avoid segfault.
Fixes: de7acc3a46 ("preproc: defer %00, %? and %??
expansion for nested macros, cleanups")
Reported-by: C. Masloch <pushbx@ulukai.org>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392640
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Add the test code into the existing xdefine testing.
Suggested-by: C. Masloch <pushbx@ulukai.org>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392630
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
The code used to stuck in going through whitespace tokens.
Fix to increment towards on the next in the loop.
Reported-by: C. Masloch <pushbx@ulukai.org>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392630
Suggested-by: C. Masloch <pushbx@ulukai.org>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
There are many similar preprocessor loop cases but located
on each bug-report basis. While it looks to be better to
consolidate them together, add one more test case like what
was done before.
Suggested-by: C. Masloch <pushbx@ulukai.org>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392626
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
The code has been fixed to print the corresponding line
numbers of %rep blocks correctly, but only for the first
iteration. For the subsequent iterations, the current line
number on the expansion needs to be explicitly reset again.
Fixes: ab6f831955 ("listing: when listing lines in macros
and rep blocks, show the actual line")
Reported-by: C. Masloch <pushbx@ulukai.org>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392626
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
