If package can't be retrieved we should not attempt
to dereference NULL'ed pointer which leads to segmentation
fault.
Reported-by: Serge
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
The corner case is the code like
%define foo 1
%push bar
%$foo:
%pop
for which v2.07 ends up with "foo = 1" while 0.98.39
issue an error.
hpa said that ideally we may need to create a context
structure for the global context but this seems to be
too agressive for 2.08.
Based on patch from nasm64developer
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
The first argument passed on stack with "flat64" stack model
(stack frame with base pointer) should be pointed by
[rbp + 16].
Signed-off-by: Per Jessen <per@computer.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Frank reported:
|
| From the "expert questions" forum comes this:
|
| ---------------------
| By: jasper_neumann
|
| How can I delegate %undef?
|
| In the example below the assembler (called with "nasm.exe -t -f rdf q.asm")
| bemoans my code, displays
|
| "q.asm:19: error: interminable macro recursion"
|
| and hangs.
|
| q.asm
| -----
| bits 32
| CPU P4
|
| %macro my_def 2
| %xdefine %1 esp+%2
| %endmacro
|
| %macro my_undef 1
| %undef %1
| %endmacro
|
| global check_it
| check_it:
| my_def x,4
| mov eax,[x]
| my_undef x
|
| my_def x,8
| add eax,[x]
| my_undef x
| ret
|
So in case of interminable macro recursion we should break
the expansion procedure that way to not return back and start
expand macro again.
This address a part of the original problem.
Nasm64developer pointed out:
|
| Btw, after you manage to fix this recursion problem, the code
| in question still faces the same fundamental issue -- the arg
| to the my_undef invocations (i.e. x) gets expanded first; thus
| the %undef inside the macro sees esp+4 and esp+8 instead
| of x, and fails. What you'd need is a means to prevent the ex-
| pansion -- look for e.g. %# in 4.1.4 of the manual.txt which is
| attached to SF #1842438; it implements exactly that -- I once
| filed SF #829879 for this feature.
|
In turn Keith Kanios said:
|
| Anon is also correct in that we would need a special directive to instruct
| the delay of macro expansion, although I don't see this as critical or even
| high priority at the moment. The intermediate solution for this is, don't
| use indirection if it is not needed... an inline %undef should be
| sufficient.
|
Reported-by: Frank Kotler <fbkotler@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Reviewed-by: Keith Kanios <keith@kanios.net>
We only ever invoked the preprocessor with fixed values for efunc and
evalfunc, so call nasm_error() and evaluate() directly.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Strings returned by nasm_unquote() can contain NUL characters, which
will not be legal if then used as a C string. Create a general
function which looks for NUL characters in the string and issues an
error if they are found.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
When the user generates an error via %warning, %error, or %fatal,
treat is as any other error message. The attempt at making them stand
out really looked ugly when the preprocessor adds additional tracing
information.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
We always need to process %+ at least once, but we also always need to
reprocess smacros after pasting. The solution to this is to make sure
we always reprocess %+ after the first expansion pass.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Revert to the earlier behavior of not expanding %+ until the final
phase of smacro expansion. However, the previous code has:
if (expanded && paste_tokens(&thead, true)) {
... which would inhibit paste_tokens() if expanded was false on the
first iteration. However, if expand_mmac_params is not expanding %+,
then we cannot bypass this expansion. Thus use:
pasted = paste_tokens(&thead, true);
if (expanded && pasted) {
... instead.
This seems to work with both Syslinux and x264 usage, and therefore
hopefully should be compatible with earlier versions of NASM.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
*To the best of my knowledge*, we now have authorization from everyone
who has significantly contributed to NASM in the past. As such,
change the license to the 2-clause BSD license.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add copyright headers to the *.c/*.h files in the main directory. For
files where I'm sure enough that we have all the approvals, I have
given them the 2-BSD license, the others have been given the "LGPL for
now" license header. Most of them can probably be changed after
auditing.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
When processing an unparsable TASM argument, convert it to %if 0 which
is guaranteed to not happen, rather than %ifdef BOGUS.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Preexisting code seems to rely on %+ being processed even during early
token replacement, e.g. Syslinux contains the following code:
%macro superb 1
bx %+ %1 equ SuperInfo+($-superblock)*8+4
bs %+ %1 equ $
zb 1
%endmacro
... which is expected to work when invoked as:
superb Media
As a result, set handle_paste_tokens to true at all times; assuming
this turns out to be the way things are we can really just remove it
as an option.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Unify the token-pasting code between the macro expansion and the
preprocessor parameter case. Parameterize whether or not to handle %+
tokens during expansion (%+ tokens have late binding semantics.)
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Recognize $ and $$ as TOKEN_OTHER; they aren't really either
TOK_NUMBER nor TOK_ID, even though we have traditionally considered
them TOK_NUMBER.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
"+" can be a separate token that ends up having to get pulled into the
middle of a floating-point constant. It's not even that strange.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Especially when token pasting involves floating-point numbers, we can
have some really strange effects from token pasting: for example,
pasting the two tokens "xyzzy" and "1e+10" ends up with *three*
tokens: "xyzzy1e" "+" "10". The easiest way to deal with this is to
explicitly combine the string and then run tokenize() on it.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The documentation says that constructs with %$...$foo can be used
to access macros from deeper in the context stack. From what
I can tell, that has never actually worked, since we'd enter names
like %$foo into the context-local macro name table. Instead, only
insert the tail of the macro name into the context-local table;
expand get_ctx to also return a pointer to the macro name proper;
this is rather straightforward since we'd usually save away that
name at the point get_ctx is called anyway.
These two really need to be done together, in order for constructs
such as %[%1] to work properly. Furthermore, fix a token-pasting bug
in expand_mmac_params().
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Use expand_id() for the argument to %use, instead of expand_smacro().
This really makes more sense for a "naked" argument. This is a
semantic change, but is unlikely to break any real code.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Allow the %pop directive to take an identifier (an assert on the
context name); unify the parsing parts of %push, %repl, and %pop.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Fix the case where the terminal token pastes with the first token of
the unmodified sequence. This is a really ugly version; we need to
merge the two instances plus the one in expand_mmac_params().
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
When locating the end of a %[...] construct, we need to end up with
the pointer pointing to the terminating character.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Linked lists where an element may be deleted or substituted during
processing can be subtle to deal with. Fix the iteration conditions
in this particular case.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add a new builtin macro, __PASS__, which is either 1 (for a
preparatory pass), 2 (for a final pass, including preprocessor only),
or 0 (for dependency generation.) This might be useful in special
contexts.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Since the error directives, including %warning, are now issued in the
final pass only, it is important that we do *not* pass ERR_PASS1 with
%warning. Rather than playing even more ugly games in error(),
require ERR_PASS1 to be passed in with warnings elsewhere in the
preprocessor, just like the rest of the system.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
