Add warnings.src to PERLREQ. If this isn't done, warnings.src ends up
in the xdoc tarball rather than the release tarball, which means that
unless the user can "make warnings" manually (which requires Perl)
then they can't build the documentation.
As this only affects the documentation build, it probably does not
warrant a point release.
Add a few more extensions to the list of recognized binary extensions
for the purpose of generating a .zip file with DOS line ending
conventions.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Fix the version information for various sections and generalize their
implementation. Drop issuing an empty .debug_pubnames section; like
other sections DWARF parsers seem to be unhappy about a section with
null content.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
It seems DWARF parsers get really snippy about a section which only
contains an end token. Instead, leave unused sections empty. Already
did that with .debug_frame, do it with .debug_loc too.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
If the source code is large, it is very reasonable for the symbol
table length to exceed 2^16 bits. Use uint32_t to keep track of
lengths, even where not necessary... there is no real reason to use
uint16_t anywhere.
Reported-by: <michael@mehlich.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
There is no reason why we should not emit debugging output when
compiling test files for manual analysis, quite the contrary.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Document new operators, removal of special casing for %if, and the
MASM-like enhancements to the Dx directives.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The cv8 output format would generate an invalid .debug$T section,
containing repeated invalid records, none of which are actually used
(which is probably the only reason it actually worked.)
Just in case, generate a *single* type record for void func(void);
Furthermore, the argument list record should come before the procedure
type record (forward references are at least normatively prohibited.)
Reported-by: Alexandre Ganea <alexandre.ganea@ubisoft.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The a64 instruction patterns would incorrectly force REX to zero at a
point where REX prefixes have already been assigned. This is not only
incorrect in case of instructions which can use high registers, but it
causes an assertion failure. It happened to work for J*CXZ and LOOP*.
Reported-by: Philip Lantz <philip.lantz@intel.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Haiku apparently wants to include <float.h> rather than
"float.h". Rename float.[ch] to floats.[ch] to avoid unnecessary
namespace confusion.
Reported-by: <alaviss0+nasm@gmail.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Until such time that we have a CFI code generator, leave .debug_frame
empty.
Reported-by: Philip Craig <philipjcraig@gmail.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Filenames with double spaces need to be quoted; the preprocessor will
otherwise collapse spaces into one.
When comparing for control characters and spaces, use an unsigned
compare.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
%line directives really need to be preprocessed early, before normal
directive processing. In particular, they are *not* affected by such
thing as smacro expansion, or deferred into an mmacro expansion.
The %line directive is special because it is explicitly indented to be
inserted by an external preprocessor, which can happen at any point.
For mmacro and rep expansions, store the current file and line for
each expansion line. Similarly, let each istk entry contain such
information.
Don't emit empty lines in preprocessing-only mode when we are
already required to issue a %line directive anyway. This cuts down on
clutter a fair bit.
Quote filenames in %line directives (and accept quoted filenames in
%line directives) if and only if it is necessary for
disambiguation. This is required if:
1. The filename contains control characters;
2. The filename begins or ends with whitespace or a quotation mark;
3. The filename is empty.
Otherwise issue the filename as-is, for backwards compatibility.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
tok_set_text() and tok_set_text_free() take a length argument, which
could at least theoretically mean that we don't have a null-terminated
string. Directly enforce a null-terminated string in all cases.
In the future this means that it is legal to intentionally use these
functions to tokenize a substring.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
In tok_set_text() and tok_set_text_free(), don't trust that
the caller has given us a zero-terminated string.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Legacy multi-line macro argument expansion really is very
complicated. With these changes, all legacy tests seem to pass, and
the only differences with NASM 2.14.xx are that some macros which
should have been expanded and were not now are.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The handling of empty arguments in NASM 2.14 and below was at best
"interesting"; a single whitespace token expansion, which can happen
during macro expansion, would sometimes be counted as an argument and
sometimes not.
One really weird effect of this was that %0 doesn't always match the
permitted range in the macro specification!
Add some backwards compatibility code to make x264/ffmpeg compile.
Add override via:
%pragma preproc sane_empty_expansion true
Add support for %clear to clear specific subsets of the macro
definitions. In particular:
%clear defalias
... can be used to wipe the __FOO__ backwards macro compatibility
aliases which may interfere with the C namespace.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
mstk.mstk reflects %rep conditions as well as actual expanded
macros. However, in_progress is undefined for %rep loops; we instead
want to look at the underlying mmacro, if there is one.
Discovered trying to compile x264.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The error message "comma expected after operand 2" no longer
occurs in this program, this is an acceptable divergence, however.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
When using VCMP and VPCMP operations with the condition in the opcode,
we should not have an immediate operand!
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
%ifdef should accept any argument count. However, requiring
a macro structure return means we have to use the wildcard
argument number (-1), not 0 meaning exactly 0 arguments.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Legacy NASM behavior is (quite frankly the sane one) that a comma
inside a set of parentheses do not split smacro arguments, unless
explicitly using braces to enforce this behavior. Revert to legacy
behavior, which again, is arguably the more correct.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
CMPXCHG8b/16b should be legitimate with an explicit operand size.
Reported-by: Xusheng Li <xushengli@protonmail.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
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>
