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>
Add a %pragma to set (or clear) listing options. It only takes effect
on the next assembly pass, however!
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
"compiler.h" already includes a bunch of common include files. There
is absolutely no reason to duplicate them in individual files, and in
fact it robs us of central control of how these files are used.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
For almost everything we should use "nctype.h". Right now we don't
have a nasm_toupper() to use <ctype.h> for things that need toupper().
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
There is absolutely no reason not to include <string.h> globally, and
with the inline function for mempcpy() we need it there anyway.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
It is extremely desirable to allow the user fine-grained control of
warnings, but this has been complicated by the fact that a warning
class has had to be defined in no less than three places (error.h,
error.c, nasmdoc.src) before it can be used in source code. Instead,
use a script to define these via magic comments at the point of use.
This hopefully will encourage creating new classes as needed.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
The prefix ERR_WARN_ is unnecessarily long and may be a disincentive
to create new warning categories. Change it to WARN_*, it is still
plenty distinctive.
This is equivalent to nasm-2.14.xx checkin 77f53ba6d4.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
There are cases where we may want to implement generic pragmas, while
still make them selective based on output and/or debug formats.
Initially, use this for the prefix/suffix options.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Chang Seok Bae <chang.seok.bae@intel.com>
Make any "deadman"-style execution limit configurable on the command
line (--limit-foo) or via a pragma (%pragma limit foo).
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
In order to support Mach-O better, add support for subsections, as
used by Mach-O "subsections_via_symbols". We also want to add
infrastructure to support this by downcalling to the backend to
indicate if a new subsection is needed.
Currently this supports a maximum of 2^14 subsections per section for
Mach-O; this can be addressed by adding a level of indirection (or
cleaning up the handling of sections so we have an actual data
structure.)
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
"output" and "debug" are supposed to redirect to the current output
and debug formats. Fix it so it actually does.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Add a generic facility for generating perfect string hashes, where all
that is needed is an enum and a string table. The existing mechanism
using a custom Perl script wrapped around a module continues to be
available for any use case where this particular approach isn't
sophisticated enough.
Much of this patch comes from renaming "enum directives" to "enum
directive" as a result of the string hash generator expecting a set of
uniform naming conventions.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Passing an object to nasm_zero() allows us to use it on arrays.
Otherwise the array will decay to a pointer and silently clear only
the first member of the array!
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
If the handler is NULL, then all pragmas are by definition unknown, so
treat them exactly as if we had received DIRR_UNKNOWN from the
handler.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Very few things have any desire to do its own string parsing, and the
directives hash is already a plain string-to-numbers O(1) hash. The
namespace is small enough that even if it makes some switch statements
compile a bit larger there is no real reason to have separate hashes,
even if the actual code as opposed to the data structure was shared.
So, for right now, just throw them together in one big happy pot.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
