Commit Graph

411 Commits

Author SHA1 Message Date
H. Peter Anvin (Intel)
14f41b2319 hash generators: rename UNUSED to UNUSED_HASH_ENTRY
The name UNUSED is too generic and may conflict with future
macro definitions. This is machine-generated code anyway, so
rename UNUSED to UNUSED_HASH_ENTRY.

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
2020-06-30 09:17:41 -07:00
H. Peter Anvin (Intel)
43a72dd638 listing: list short reserved blocks as ?? instead of <res ...>
<res ...> can get rather annoying when mixed in with data, as can
happen with the MASM-like db syntax. List shorter blocks (8 bytes or
less) as ?? instead; 8 bytes avoids line breaks for a single
statement.

This is probably more readable anyway...

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
2020-06-27 23:30:33 -07:00
H. Peter Anvin (Intel)
de8817ddbc doc: clean up warnings formatting
When a warning documentation message contains more than one paragraph,
we have to indent the subsequent paragraphs using \> unless they are a
code paragraph (\c).

Improve a few warnings doc messages.

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
2020-06-27 22:30:50 -07:00
H. Peter Anvin (Intel)
d85a6101d7 BR 3392681: handle a64 instruction patters correctly
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>
2020-06-22 13:52:02 -07:00
H. Peter Anvin (Intel)
6e9554f067 BR 3392648: rename float.[ch] to floats.[ch]
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>
2020-06-14 23:24:43 -07:00
H. Peter Anvin (Intel)
3957f6f831 %line: quote filenames with double spaces, use unsigned char check
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>
2020-06-14 20:17:57 -07:00
H. Peter Anvin (Intel)
b292748d9f preproc, srcfile: much saner handling of %line directives
%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>
2020-06-14 20:09:11 -07:00
H. Peter Anvin (Intel)
4ed23c8f85 preproc.c: make extra sure we always have a null-terminated token
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>
2020-06-14 19:55:49 -07:00
H. Peter Anvin (Intel)
00335e43ef preproc.c: make extra sure tokens are always null-terminated
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>
2020-06-14 19:49:19 -07:00
H. Peter Anvin (Intel)
42894381c9 preproc: even more handling of backwards compatibility for mmacros
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>
2020-06-14 19:42:22 -07:00
H. Peter Anvin (Intel)
ee0e3ec5a4 preproc: %clear options, backwards compatibility hack for x264
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>
2020-06-08 19:01:48 -07:00
H. Peter Anvin (Intel)
bacf04a3e0 preproc: need to look at mmac->in_progress not mstk->in_progress
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>
2020-06-08 13:29:06 -07:00
H. Peter Anvin (Intel)
f7fadcd245 Fix missing "here" from error messages
The "here" or "in an unknown location" suffix was inadvertently
dropped.

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
2020-06-05 13:19:45 -07:00
H. Peter Anvin (Intel)
b91e77361a preproc: %ifdef needs to accept any argument count
%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>
2020-06-05 12:22:26 -07:00
H. Peter Anvin
bd00f25a70 preproc: commas inside parens don't break macro arguments
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>
2020-06-04 21:05:01 -07:00
H. Peter Anvin (Intel)
f8639bdb52 BR 3392662: handle empty argument at end of mmacro call
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>
2020-06-04 16:29:53 -07:00
H. Peter Anvin (Intel)
283bc92a92 nasm.c: correctly print errors once committed; assert errhold_stack empty
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>
2020-06-04 16:19:51 -07:00
H. Peter Anvin (Intel)
c44709c964 preproc: don't call nasm_error_hold_push() twice
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>
2020-06-04 16:19:01 -07:00
H. Peter Anvin (Intel)
4964d80fe4 BR 3392652: hold smacro expansion warnings until we are sure
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>
2020-06-04 15:59:47 -07:00
H. Peter Anvin (Intel)
12df4dd12f asm/error.c: handle warning "all" correctly
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>
2020-06-04 15:59:47 -07:00
H. Peter Anvin (Intel)
5b4de52083 BR 3392667: more reasonable limit for expression descent
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>
2020-06-01 13:21:05 -07:00
H. Peter Anvin (Intel)
5d68f9823e preproc: error out if an include file exists but can't be opened
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>
2020-06-01 12:32:35 -07:00
H. Peter Anvin (Intel)
6e71496e3c BR 3392669: in expand_one_smacro(), we may reach EOL before tafter
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>
2020-06-01 12:21:10 -07:00
H. Peter Anvin (Intel)
7cfd01868c BR 3392668: in %define, don't set "definining" until confirmed
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>
2020-06-01 12:04:35 -07:00
H. Peter Anvin (Intel)
a762cd4e54 BR 3392668: preproc: test for macro in TOK_LOCAL_SYMBOL
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>
2020-06-01 11:49:08 -07:00
Chang S. Bae
c52aff4cc8 preproc: Fix in accessing the definition structure of a single-line macro
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>
2020-04-21 21:41:33 +00:00
Chang S. Bae
057b832f45 preproc: Fix the macro-parameter check for conditional code
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>
2020-04-21 21:28:50 +00:00
Chang S. Bae
7ee58d44e4 preproc: Fix the token in expanding the macro-parameters
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>
2020-04-21 21:12:01 +00:00
Chang S. Bae
95e54a9f1f preproc: Fix the token iterator in expanding single-line macro
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>
2020-04-21 21:11:10 +00:00
Chang S. Bae
bec812fc4b preproc: Fix to reset %rep list line number after every iteration
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>
2020-04-17 21:33:33 +00:00
H. Peter Anvin (Intel)
e91f5cc132 preproc: fix %undef of macro aliases, and add %ifdefalias
Macro aliases can legitimately point to nonexistent
macros. Furthermore, %undef should remove the pointed-at macro, not
the alias. This led to an infinite loop in the existing code; fix
that.

Add an %ifdefalias directive to test for the existence of an alias.

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
2019-10-23 12:59:06 -07:00
H. Peter Anvin (Intel)
0741eb6004 listing: make it possible to flush the listing output after every line
Add the -Lw option to flush the list file after every line
output. This is handy for debugging if nasm hangs.

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
2019-10-23 12:45:08 -07:00
H. Peter Anvin (Intel)
4b58ec1b8f preproc: properly protect %xdefine params (see below), cleanups
1. %xdefine was broken because the code used i as a loop, which is
   a standard use for the name i. To avoid that confusion in the
   future, use "op" rather than "i" to hold the directive constant.

2. Once (1) was fixed, the smacro expansion code would fail because of
   parameter token numbers being indistinguishable between the ongoing
   expansion and the %xdefine parameters. In a first pass, mark the
   parameters with a new TOK_XDEF_PARAM token number, and change them
   to proper parameter token numbers in a second pass, which is now
   moved into define_smacro() which is where it arguably belongs.

3. Add a few tests for token pasting and xdefine with and without
   parameters.

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
2019-10-23 12:00:50 -07:00
H. Peter Anvin (Intel)
f770ce8be4 preproc: reserve space for terminal NUL in %strcat
Technically, this is not necessary, because make_tok_qstr_len()
doesn't rely on NUL termination, and in fact it *can't*, since the
string might contain embedded NULs, but tacking on a NUL is good for
debugging if nothing else. That means reserving space for it!

Reported-by: C. Masloch <pushbx@ulukai.org>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
2019-10-17 18:22:43 -07:00
H. Peter Anvin (Intel)
18f4134222 preproc: fix %strcat and %substr
Fix incorrectly running off the end of the intended string for %strcat
and %substr.

This is a modified version of a patch contributed by C. Masloch.

Reported-by: C. Masloch <pushbx@ulukai.org>
Originally-by: C. Masloch <pushbx@ulukai.org>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392599#c11
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
2019-10-16 15:02:44 -07:00
H. Peter Anvin (Intel)
e86fa7fffd preproc: %xdefine must process arguments before expanding
The only way in which
    %xdefine(xxx) yyyy zzzz
differs from
    %define(xxx) yyyy %[zzzz]

is that in the former case macro arguments get preserved, even if
they are macros defined elsewhere. Revert to that behavior.

Reported-by: C. Masloch <pushbx@ulukai.org>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392623
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
2019-10-16 14:51:16 -07:00
H. Peter Anvin (Intel)
84b852bff0 Implement an enhanced version of MASM's dup() and "db ?" syntax.
Add support for complex data (Dx) statement expressions involving both
initialized and uninitialized data. In addition, we have support for
overriding the size of each element on an individual item and/or list
basis.

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
2019-10-16 14:29:16 -07:00
H. Peter Anvin
d03a6c8ffe preproc: fix the detection of the >= operator
There are *four* operators starting with ">": > >> >>> and >=.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2019-10-07 21:29:05 -07:00
H. Peter Anvin
d983b62233 preproc: make %exitrep do what it is supposed to
%exitrep should should stop emitting code immediately, not just
terminate the loop when we hit %endrep. There is a bunch of hacky code
that special-cases that using istk->in_progress == 0.

The handling of the tail of %exitrep, %include and non-emitting
conditionals using entirely different mechanisms is just dumb. They
need to be unified.

Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392612
Reported-by: Jason Hood <jadoxa@yahoo.com.au>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2019-10-07 21:25:18 -07:00
H. Peter Anvin
58bd8e6644 warnings.pl: correct the documentation output for aliases
Expand the list of aliases, not the prefix "="!!

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2019-10-07 21:11:13 -07:00
H. Peter Anvin
bef71a86b9 warnings: do a line break before enabled/disabled note
We need to create a separate paragraph if the help text had used \c
anyway. Putting the enabled/disabled separately for all entries makes
it read a lot cleaner anyway.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2019-10-03 23:47:08 -07:00
H. Peter Anvin
7ad824be7a warnings: make it possible to put blank lines in doc text
rdsrc.pl requires blank lines around \c paragraph, but warnings.pl
would strip them. Create a *!- prefix to force a blank line.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2019-10-03 22:18:35 -07:00
H. Peter Anvin
1dd926e8ce pragma: handle default name/fallback handler for NULL list; cleanups
The previous code would fail to process any directive if the directive
list was NULL. However, we also need to process the default name
passed to search_pragma_list() (e.g. "elf32"), as well as the global
name (e.g. "output") and call the default handler in that case.

In the process, improve the handling such that if one handler returns
DIRR_UNKNOWN, try calling subsequent handlers in the list.

Finally, factor out as much as possible to generic handlers.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2019-09-30 13:30:15 -07:00
H. Peter Anvin
8571f06061 preprocessor: major cleanups; inline text into Token
Major cleanups of the preprocessor. In particular, the
block-allocation of Token is pretty ridiculous since nearly every
token requires a text allocation anyway. Change the definition of
Token so that only very long tokens (48+ characters on 64-bit systems)
need to be stored out of line.

If malloc() preserves alignment (XXX: glibc doesn't) then this means
that each Token will fit in a cache line.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2019-09-23 16:40:03 -07:00
H. Peter Anvin (Intel)
f7dbdb2e13 preproc: fix multiple memory corruption issues
paste_tokens() would not null-terminate the buffer before passing it
to tokenize(), resulting in garbage or a memory overwrite.

In several places the next pointers got confused; sometimes causing a
circular list and sometimes an invalid pointer.

Some minor code cleanups while fixing things, too...

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
2019-09-18 21:20:52 -07:00
H. Peter Anvin (Intel)
f24d975008 preproc: fix list corruption bug; clean up token handling
expand_one_smacro() would corrupt the end of the list if a macro
expanded to another macro with arguments, which was also the last part
of the expansion.

Instead of doing all that testing with ttail, just scan forward at the
end to find the tail pointer; it is O(n) regardless.

Clean up the handling of tokens: use inline functions rather than odd
macros that sometimes modify their arguments and sometimes don't, and
fold some common code into new functions.

The tok_is() and tok_isnt() functions always are used with single
characters, so make it explicitly so (and remove the local hacks used
in some places.)

Allow using nasm_malloc() rather than blocked Tokens; this makes tools
like valgrind more useful in their reports.

For the future, consider making Tokens a separate memory allocation
immediately followed by the text, instead of using a pointer; we
allocate space for the string in almost every case anyway. Also
consider making it a doubly linked list...

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
2019-09-18 18:17:26 -07:00
H. Peter Anvin
dd88aa9a1b preproc: add %ifusable and %ifusing directives
%ifusable tests to see if a certain %use package is available in this
version of NASM.

%ifusing tests if a certain %use packages is already loaded.

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
2019-09-12 19:39:48 -07:00
H. Peter Anvin
a039fcdb46 preproc: move %use package parsing to a separate routine
Move the parsing of %use package names to a separate routine, and stop
using get_id() for that purpose -- get_id() is wrong in a number of
ways.

This also means we can drop the error string argument to get_id().

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2019-09-12 19:27:42 -07:00
H. Peter Anvin
14f0328aa1 eval: don't try to poke *opflags if opflags is NULL
While changing this code around to not do redundant lookups, dropped
this NULL pointer check. Oops.

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
2019-09-12 18:34:14 -07:00
H. Peter Anvin
d626f355f6 preproc: correct handling of %ifdef for aliases
Correctly handling %ifdef when operating on aliases; we had an
infinite loop going...

Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
2019-09-12 18:31:29 -07:00