%unmacro now *is* permitted on a macro being expanded; the entire
expansion is strictly performed when the macro is invoked, and the
lifetime issue related to %unmacro and %exitrep has been hacked
around.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
This code incorrectly would try to use "path" as the hash key instead
of full->path, causing the key in struct hash_insert to diverge from
the one used in hash_add(). Fix that.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Under some circumstances, such as:
- Certain uses of %exitrep in syntactically invalid code;
- %unmacro of a *alias* to a macro currently being expanded;
... it is possible for an mmacro to get freed while it is still in
use. Although inefficient, the easiest way to avoid this is to not
free mmacros until the end of pass cleanup, when named mmacros are
also freed.
To support this, use the existing ->next field in the MMacro structure
to keep a list of anonymous or removed MMacros. Don't free ->name at
this point, though, since that is currently used to distinguish
between %rep's and %macro's. (This needs to be cleaned up to support
constructs such as %while or %for, but that is for later.)
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
UD0 without a modr/m is obsolete in terms of syntax, but not as an
instruction per se. Match UD1 and assemble it without warnings, but
disassemble it with operands.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The opcode D6 has been officially reserved as a single-byte permanent
undefined (#UD) opcode in 64-bit mode with the mnemonic UDB. This is
already the behavior of all known 64-bit implementations; this is thus
merely an official statement of forward compatibility and the
assignment of a mnemonic.
This will be documented in the next version of the Intel Software
Developer's Manual; in the meantime I DO speak officially for Intel on
this issue.
The x86 Advisory Council has ratified this decision, and so it is
expected to be honored across vendors, but I obviously cannot make any
official statement on any other vendor's behalf.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Tidy up the way path syntax selection is handled, and make it possible
to specify it outside this file (e.g. in a Makefile) if need be.
Haiku, like BeOS, uses Unix syntax.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The handling of "path" and "fullpath" was inconsistent, resulting in a
lot of missing dependencies regardless if a separate build directory
was in use.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The help output has gotten way too long to be shown on a single
command line. It can of course be piped to a pager, but to be a little
nicer to the user, break it up into subtopics that can be individually
displayed. --help all (-h all) can still show all the help information
as a single data dump.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add Obsoletes tags: nasm-rdoff; old nasm-doc.
Add a few BuildRequires: tags.
Update License: tag to match SPDX.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
PA_ADD_LANGFLAGS() was broken, resulting in among other things
--enable-lto not working.
Make autogen.sh fail if aclocal return error.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
This target exists; use it, instead of effectively open-coding it into
the release script, causing bit rot and testing problems.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Assume module names (for "use") always start with a capital letter,
and that anything that doesn't is a pragma.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Don't break Makefile.dep generation if run from a separate build
directory.
config/unconfig.h is a bit special; it is kept in the repository for
the benefit of non-configure users. Therefore, don't have "make
spotless" delete it.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Try to better sort out the necessary dependencies for warning
generation.
Fix regex for cleaning up nasmdoc markup: nasmdoc markup does not
nest, although it may include \} sequences.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Without a manifest, Windows applications force a fixed PATH_MAX limit
to any pathname; this is unnecessary.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Comment was missing a semicolon; fix to avoid unnecessary warning and
to make sure the documentation is generated correctly.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
