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>
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>
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>
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>
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>
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>
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>
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>
%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>
It turns out that we need a Fontmap file after all, *and* -I. to make
gs find it. Inconsistent results came from stray Fontmap files from
previous debug attempts.
Now generate both fontpath and Fontmap, and hopefully at least one of
them should work. We might, in fact, need both, one for gs to know
where the files are and one for gs to know it is allowed to read them.
The core problem seems to be that gs will find OTF fonts by its normal
discovery mechanisms, but for some reason don't seem to use them
unless it can find them in a Fontmap, Font directory, of CIDFont
directory.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
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>
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>
config/config.h as generated by autoconf has #undef directives
commented out, but the autoheader-generated template contains them,
and config/unconfig.h should not contain them. Re-introduce
config/config.h.in, and postprocess it to generate config/unconfig.h
by commenting out all the #undef directives, just as configure does.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
<config/unconfig.h> is generated by autoconf (autoheader), but just
like the autoconf/helpers directory contains files for people who
don't have the proper tools, check this file in.
It should even be less annoying change-wise than the helpers...
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
\\?\ is supposed to override the hard-coded path limit, but it has
other effects as well, such as not working with relative paths and
paths containing /. On Windows 10 it is possible to set a registry key
to override this option anyway.
Maybe one day we can just use fopen() like on normal systems, even...
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Link: https://bugzilla.nasm.us/show_bug.cgi?id=3392614
Reported-by: Iouri Kharon <bc-info@styx.cabel.net>
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>
The inlining of preprocessor tokens has benchmarked about 15% faster in any
realistic scenario than the old code. For an artificial case where
over 50% of symbols are longer than 47 characters there was a slowdown
of about 15%, but that represents an incredibly unlikely scenario in
practice: even if labels are that long (e.g. C++ name mangling) the
majority of tokens should be instructions and registers, which are
uniformly short.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Updating the autoconf helpers unconditionally is very noisy and
probably the wrong thing to do anyway. Check the version numbers and
only update if the current machine has a newer version installed.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
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>
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>
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>
