Get rid of the completely pointless "debuginfo" parameter to
ofmt->cleanup(). Most backends completely ignore it, and the two that
care (obj, ieee) can simply test dfmt instead.
Also, dfmt is never NULL, so any test for a NULL dfmt is bogus.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
We pass around a whole bunch of function pointers in arguments,
which then just get stashed in static variables. Clean this mess
up and in particular handle the error management in the preprocessor
using nasm_set_verror() which already exists.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
From master branch checkin 130736c0cfcad28ee16cec6c14bb22999d982e5a
Resolved Conflicts:
nasm.c
preproc-nop.c
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Replace all instances of ERR_FATAL or ERR_PANIC with nasm_fatal or
nasm_panic so the compiler knows that these functions cannot return,
*and* we trigger abort() if we were to ever violate that constraint.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
size is actually an uint64_t, and LLVM drops the abs() on the
principle that the uint64_t should always be positive. Make it
explicit that we are converting to a signed integer first, by using
abs((int)size) instead.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
This is a a buffer on stack big enough to hold
bigger object we might need (address, number and
etc) but it's defined as an array of bytes and
we treat it as different types depending on context,
which may lead to situation where data from stack
been treated as meaningful.
In particular in commit 5b730a197 we've fixed such
problem simply using a "big" write to zeroify stack
data before use.
Lets simply zeroify this buffer explicitly to escape
such problems in future.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
While we using proper @asize variable for relocation itself
we miss the fact that @size variable (which might be negative
for signed relocations since fd52c277dd6) is used to calculate
section size increment.
http://bugzilla.nasm.us/show_bug.cgi?id=3392299
Reported-by: Ben de Waal <ben@dewaals.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Instead of having unchecked fwrite() calls, introduce nasm_write()
which does error checking (and fatal errors if the write fails).
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
In commit fd52c277dd6d768545cee39b154e706904581966
we've started handling negative address relocations
but support Elf format only and got a typo in bin
format which leaded to endless cycle of applying
relocation due to negative argument (make test
hangs).
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Instead of opencoded zero assignments better to use nasm_zalloc
and set fields which are supposed to be non-nil. This simplifies
code and makes it more readable.
Also note the field 'ifollows' renamed to 'prev' as it should
be from the very beginning in terms of lists.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
In commit 55ae12052cd1 we occasionally broke byte ordering. Fix it.
Note that current stable version 2.08.01 is not affected by this bug.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Add OUT_REL1ADR (one-byte relative address) and support for
OUT_ADDRESs with size == 1. Add support for it in
outbin and outdbg. *It still needs to be added to other backends*,
both the OUT_REL*ADR and OUT_ADDRESS codepaths need to be handled.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
format_mode is always set to 1 so there is no need to
keep this variable. "Old chicken bit" (c) :)
Reported-by: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Instead of manipulating stdscan buffer pointer directly
we switch to a routine interface.
This allow us to unify stdscan access: ie caller should
"talk" to stdscan via stdscan_get/set routines.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
We never set ofmt and errfunc to anything but the global values.
Dropping them from the label definition function command line
simplifies the code.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Remove a bunch of function pointers in the output stage; they are
never changed and don't add any value. Also make "ofile" a global
variable and let the backend use it directly.
All we ever did with these variables were stashing it in locals and
using them as-is anyway for no benefit.
Also change the global error function, nasm_error() into a true
function which invokes a function pointer internally. That lets us
use direct calls to it.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Hash all directives, even the ones that are backend-specific,
and instead pass the backend an already-parsed directive number.
Furthermore, unify null functions across various backends.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
We fopen() the output file in common code but fclose() it in the
backend. This is bad for a variety of reasons:
1. it is generally an awkward interface to change ownership.
2. we should use ferror() to test for write errors, and that is
better done in common code.
3. it requires more code.
4. we still need to fclose() in common code during error handing.
Thus, move the fclose() of the output out of the backends, and add
fflush() so we can test ferror() on output.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The documentation uses "Intel hex", with that capitalization (Intel
being a proper noun, hex being descriptive) so make the help message
match.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
- add assert so we don't try to write 2^64 bytes of zero
- explicitly track the Intel hex "LBA" (64K page) instead of playing
games with the last byte written. This way it is more explicit
what we're doing and why.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Using saa_fpwrite() to dump a section to a file automatically does
saa_rewind(), but if we use saa_rnbytes() to do bit by bit then we
manually need to to saa_rewind() before we start.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add support for directly generating Intel hex or Motorola S-records.
These formats are commonly used with ROM burners.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Allow the backend to specify that an output format is either text or
binary. For future uses, define this as a flag word so we can define
other flags in the future if it would make sense.
Currently, the ieee and dbg formats are text; all the others are
binary.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add new copyright headers to the new output modules. As far as I
know, the only module which we still don't have a green light to
release under 2-BSD is outmacho.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Move backend-specific code into the output/ directory, and make the
null debugging backend a separate file (it certainly isn't needed for
ndisasm...)
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Some vendors get nervous about parameterized printf patterns;
furthermore, it's completely unnecessary in this case.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
When a section other than .text has a start < origin, we would
segfault; fix that.
Furthermore, at bin_cleanup() we don't have usable file/line
information, so pass ERR_NOFILE to the error() function. Perhaps less
than ideal, but better than printing a null pointer.
Add a common file, outlib.c, for output formats. Add the function
realsize() instead of open-coded variants in almost every backend.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The "bin" format was misinterpreting the overloading of the "size"
argument to out(), which caused another source of 64-bit relative
offset errors.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
ctype functions take an *int*, which the user is expected to have
taken the input character from getc() and friends, or taken a
character and cast it to (unsigned char).
We don't care about EOF (-1), so use macros that cast to (unsigned
char) for us.
Move the handling of "extra" macros (i.e. output format macros) into
the macros.pl mechanism. This allows us to change the format of the
internal macro store in the future - e.g. to a single byte store
without redundant pointers.
Also, stop using indicies into a long array when there is no good
reason to not just use different arrays.
Fix one missed change from "type" to "size". May want to look through
all the other backends as well for similar issues.
This would generate the wrong section lengths, with obviously bad results.
Address data is always int64_t even if the size itself is smaller;
this was broken on bigendian hosts (still need testing!)
Create simple "write sized object" macros.
