NASM 2.15.04
Conflicts:
asm/listing.h
asm/pptok.pl
asm/preproc.c
version
This doesn't pass travis test 3392711, which is using an extremely odd
construct of %?? in the middle of an argument sequence for an smacro
while not being in a macro itself, and expecting it to expand to the
macro name. This seems to *really* confuse the master branch.
Resolve this later...
At least DWARF can encode C-style macros. In doing so, it wants the
file include hierarchy, so give the debug format backend the option of
receiving that information from the preprocessor.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The mempcpy helper returns *last* byte pointer thus when
we call set_text_free we have to pass a pointer to the
start of the string.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Make sure the data being freed get double
freed after -- the pointers must be zapped
(actually nasm_free and free_tlist support
being called with NULL pointer as an argument).
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
After issuing an error message for a missing %stacksize argument, need
to quit rather than continuing to try to access the pointer.
Fold uses of tok_text() while we are at it.
Reported-by: Suhwan <prada960808@gmail.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The %? and %?? tokens are ambiguous when used inside a multi-line
macro. Add tokens %*? and %*?? that only expand during single-macro
expansion.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
If macros are nolisted, *or* they don't have any filename associated
with them, it is absolutely pointless to try to descend into them for
error messages, so just don't, even if -Lb is provided.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The previous code to fix whitespace around and multiple %+ symbols in
a row (checkin 122c5fb75986adc37dfb147cc2a613e3ebc66e80) had some
seriously broken pointer handling when zapping tokens. This could
cause paste_tokens() to go into an infinite loop because it would
attach %+ to another token and then immediately break them apart
again, over and over.
Reported-by: <alexfru@gmail.com>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The different token codes between the preprocessor and the assembler
is a completely unnecessary headache. Furthermore, lumping all the
operators under TOK_OTHER in the preprocessor causes a whole bunch of
unnecessary headaches.
In combining them, the only tricky part is that PP_CONCAT_MASK() is no
longer usable, as the range of token codes is too large. Replace with
dedicated category masks.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
To handle escape codes in filename strings after # markers correctly,
we need nasm_unquote() to be aware that it is using C escapes;
otherwise things like "foo`bar" will break.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
In 41e9682efed7cd1df133b1b4ac806e07723f1486 we've
changed the nasm_quote arguments still not all callers
were converted which could lead to nil dereference.
[hpa: no need to call strlen() for the asm/preproc.c chunk]
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add the first "preprocessor functions". These are simply "magic"
single-line macros with a suitable expansion function. The first
application is functions equal to the %if directives, e.g.
%ifdef blah == %if %isdef(blah) except can be used anywhere (not just
in %if statements like defined() in C.)
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
In 41e9682efed7cd1df133b1b4ac806e07723f1486 we've
changed the nasm_quote arguments still not all callers
were converted which could lead to nil dereference.
[hpa: no need to call strlen() for the asm/preproc.c chunk]
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
In 41e9682efed7cd1df133b1b4ac806e07723f1486 we've
changed the nasm_quote arguments still not all callers
were converted which could lead to nil dereference.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
NASM now supports a proper superset of cpp line number markers, so
there is no need to hack around them using the
"prepreprocessor". Instead, just put a quick test in do_directive()
treating it just like %line, except convert a "-quoted string into a
`-quoted string.
(This can break if there is a ` or \" sequence in the string... fix
that at some point. This is still much better than what there is now.)
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
When generating list output, preserve %[...] in the output if we list
a TOK_INDIRECT. The tokenization process removes these deliminators,
so we have to explicitly put them back.
This doesn't affect assembly output, which will only ever be generated
after all TOK_INDIRECT tokens have been removed, but it does affect
some of the listing modes.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Instead of %pragma ignore, use a new %null directive which ignores the
rest of the line, without bothering to expand it.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
defining->dstk.mmac should point back to "defining" when the topmost
definition block is a %macro block.
Otherwise %00 will not inhibit label emission.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The hacky %arg and %local directives build directives as strings which
they then tokenize and call do_directive() recursively with. Factor
these out and remove the recursion.
It is too bad that %arg and %local didn't include the [] brackets in
the created macros; if so it would have been possible to do something
sane with 64-bit register operands. Sigh.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
ERR_PASS1 only remains in three places:
a. Unterminated %! string, an error
- Should be signalled no matter which pass it is encountered in
b. Two cases of map file problems in outbin
- The buffered warning system take care of that issue
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
A negative number is two tokens: a minus sign and a positive
number. For most uses we still want to generate signed numbers; for
specific uses there might be motivation for an unsigned output, but in
most cases it would be confusing.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The fact that smac->expansion is stored in reverse order is a detail
of the implementation, and should not be forced on the caller of
define_smacro().
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Fold the prepreprocessor and the nop preprocessor into the main
preprocessor. This means handling # cpp-like lines and TASM
compatibility tokens in the preprocessor proper, but that is really
not very hard to do.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Reverse the invocation lists once each list is complete, so that the
lists passed to the macro backend are in true invocation order.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
We need the exact match in the rbtree for the current section. An
approximate match is not acceptable.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Collect macro call/nesting information for the benefit of the debug
back end. So far, the only backend for which this is provided is the
debug back end, to show what information is present.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
%+ tokens can end up next to each other, or at the beginning or the
end of an expansion if we try to paste the output of empty
macros. This is perhaps particularly likely to happen in %[]
expressions.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
1. Error messages would issue with the line number of %endrep.
2. Debug line information would ignore both macros and reps.
This is doubly wrong; macros are semantically equivalent to
inline functions, and it is expected that debuggers trace
into these functions.
These changes finishes the last parts of moving all responsibility for
the listing enable/disable into the preprocessor, so remove the
way over-complicated macro inhibit facility from the listing module
entirely.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The autoconf process automatically generates macros for function
attributes, including empty placeholders. Said empty placeholders also
propagate automatically into config/unconfig.h for the compilers which
don't support autoconf.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
expand_mmac_params_range() lost its "static" in checkin
e99a946390e561804bf624a1e67f25ae34b13dfd. Put it back.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Fix the handling of %{:} macro operands. Use the same code for
expanding the subarguments as for normal arguments.
This (hopefully) resolves the following bug reports:
BR 3392611, BR 3392686, BR 3392688
Reported-by: <coconutfaistoslimeregistry@gmail.com>
Reported-by: Jasper Lievisse Adriaanse <r+nasm@jasper.la>
Reported-by: Jason Hood <jadoxa@yahoo.com.au>
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
clang, unlike gcc, will warn on inline functions which are
unused. This can happen if a function is either intended to be used in
the future, or it is only used under certain config options. Mark
those functions with the "unused" attribute; not only does it quiet
the warning, but it also documents it for the user.
Shuffle around the warning options in configure and add a few more
that are specific to clang.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
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>
%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>
