It is possible on memory exhaustion that nasm_fatal() might cause
another allocation error, thus calling nasm_alloc_failed() again. If
we find us in nasm_alloc_failed() for a second time, try to get a
message out and then call abort().
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Apparently it isn't just NMAKE which is sensitive to the ordering of
.SUFFIXES, it apparently applies just as well to Unix make.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
1. The mkdep.pl program didn't handle excluded dependencies correctly,
causing it to error out due to config/config.h not existing.
2. NMAKE is sensitive to the order suffixes appear in .SUFFIXES,
causing it to try to use the builtin rule .c.exe instead of
.c.obj -> .obj.exe.
3. NMAKE doesn't handle the && operator between commands.
4. The !ifdef jungle around dependency generation was wrong.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Get rid of remaining dependencies on FILENAME_MAX, which ought to have
been removed a long time ago.
Remove ofmt->filename(); all implementations pretty much do the same
thing and there is absolutely no reason to duplicate that
functionality all over the place.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Make further autoconf rule improvements and update the required
version of autoconf to 2.69. That version is now 5+ years old and
although there might be older versions which have the prerequisite
macros they are known to have lots of bugs, and we can't really test
them.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Make it possible to keep dependency information separate from the
Makefiles, so we don't have to deal with it noisifying the git logs.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
For many (most?) targets these will be very small functions, so inline
them. However, just in case make these external library functions.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
This is a fix for a4f6ca5a33
- We should not use sole CPPFLAGS when compiling,
but rather merge it into ALL_CFLAGS
- nasm.spec.in should use DESTDIR since
INSTALLROOT now renamed to it
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
* CPPFLAGS is a user variable and should be respected
when compiling .c files. Think of -D_FORTIFY_SOURCE=2.
* Pass ALL_CFLAGS when linking too. This is recommended
for certain edge cases (-flto)
* Use DESTDIR instead of INSTALLROOT for staging dir
Every other build system (Automake, CMake, Meson) uses
DESTDIR. This integrates better into distro and other
build systems that have standard hooks for DESTDIR.
* $(MAKE) -C <dir> is better than cd'ing into a <dir>
* Use Autoconf's ${docdir} and ${htmldir} for installing
the documentation. This makes handling documentation
easier and respects user choice.
Signed-off-by: David Seifert <soap@gentoo.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Move byte order handling functions to their own header file, and try
to be more specific about how exactly to handle things.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Several output formats use "string tables", which is a collection of
null-terminated (C) strings which are referenced by a byte offset into
the string table. A single string can be referenced an arbitrary
number of times.
As this is quite simple to implement with a hash table, we do exactly
that.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Some debugging formats may need to be able to split paths into
directory name and filename, at least. This is kind of iffy, at least
across platforms, but that isn't really expected to be an issue in
practice... we hope.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Sync up with how the Fedora spec file has evolved.
Auto-generate the Perl build dependencies.
Add --enable-lto: it makes especally the rdoff files much smaller.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
We already have abort-on-error memory allocation and I/O operations in
nasmlib, so use them for rdoff as well.
Delete long-since-obsolete rdoff Mkfiles directory.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
If $(X) is not empty, it needs to be added as a suffix, otherwise the
rule .$(O)$(X) won't do anything at all.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Fix a few dumb but serious mistables in Makefile.in that prevented
anything from actually getting linked.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The standard syntax for a phony target in Make is:
target: <dependencies>
.PHONY: target
... however, Watcom WMAKE seems to use
target: <dependencies> .SYMBOLIC
and furthermore, seems to *require* it. Therefore, remove the
"perlreq" target from the automatically distributed region and move it
into the specific region; it should not need to change anyway since
the PERLREQ list itself is still synced.
If it was only a matter of the .SYMBOLIC versus .PHONY token it would
be easy enough to change that in syncfiles.pl, but this syntax change
is big enough that it doesn't make enough sense to worry about.
Reported-by: sezero <sezero@users.sourceforge.net>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Distribute the file generation rules to auxiliary Makefiles via
syncfiles.pl. These rules are OS- and Make-dialect-generic enough
that our mangling script handles them well enough.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
insns-iflags.ph is included from another Perl script, so rename it .ph
(Perl header). Add missing dependency to the main Makefile.
Signed-off-by: H. Peter Anvin <hpa@zytor.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>
Move directive processing to its own file, and move nasmlib/error.c to
asm/error.c (it was not used by the disassembler); remove some extern
declarations from .c files, and do some general code cleanups.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
We want to move the directive handling to a separate file, so change
the filename of the directive table handler to something a bit more
specific.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cleaning up hasn't really kept up to date with source code changes.
Try make it better for now; this also ought to make it easier to do
the corresponding cleaning in the *.mak files.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Most of the time we don't need the dumping code, so move it to a
separate C file to the linker can exclude it.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
There is no fundamental reason for all objects that don't contain a
main() function to not be part of libnasm.a; this allows the linker to
do its job optimally, especially in the presence of debugging code
which may not be needed under normal conditions.
If we do end up with function name conflicts the library might have to
be split, but it would be better to simply avoid that case.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Move memory-mapping functions from file.c into a separate mmap.c.
This will be cleaner especially once (if) we end up doing a Windows
implementation, which is likely to look entirely different.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Move the canned OpenWatcom configuration file to config/watcom.h.
Also exclude config/config.h from being a dependency for MSVC.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Sometimes we really want to use an extended pathname for an include
file, for documentation purposes; e.g. "config/config.h". This makes
alldeps handle that case correctly (and also adds the config/
directory to directories scanned by alldeps).
It is unclear if this will work correctly if there are include files
with the same name in different directories, but we currently do not
have any case like that.
Reported-by: anonymous coward <nasm64developer@users.sf.net>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
