If a label is redefined in the same pass, and the value is
inconsistent, then error out. While we are at it, give the source
location of the previous definition.
This explicitly rejects BR 3392535; there seems to be no reason to
reject duplicate definitions with the same value, as there is no
inconsistency involved.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add a new severity level "note", intended to be used to give
additional information about a previous error.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
If warnings are errors, print [-w+error=xxxx] and prefix error:.
Use the same spacing for filename and non-filename error messages.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
-E -MD should work and output a dependency file.
-MD can be used without a filename; there is a default filename or
-\c{-MF} can be used.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
There are probably other corner cases where we could at the very
least produce an incorrectly rounded result, so be a bit more cagey
about the description of the bug.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
When we have an exact limb switch, we may end up with a case where the
value no longer has any remaining valid bits. In that case, we end up
relying on the expression *mp |= v << ms shifting the bits on the
subsequent limb all the way to zero, but that is not how real hardware
works when the shift count equals the width of the type. This is
undefined behavior and does, in fact, produce the wrong result.
Instead, change the test for limb shift to (ms < 0), meaning that we
defer the advance to the next limb until we actually need it. At that
point, change the shift into the *old* limb to have a cast to
(fp_2limb) which means the shift right of LIMB_BITS is valid and
produces a zero value as expected.
Reported-by: Brooks Moses <bmoses@google.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The input file is provided by nasm_error(), we should not include it
in the printf list (compiler warning + wrong message.)
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
External symbols are defined via deflabel(), but deflabel() is not
called until pass0 == 1. Until that happens, segbase has no way to
know what the proper segment base of the segment actually is.
Thus, testing for pass0 == 0 will always fail for a forward reference;
correct the test to test for pass0 < 2, i.e. the assert should fail
only for the final code-generation pass.
Reported-by: <stsp@list.ru>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
If no output filename is specified, then a default filename is used
based on the input filename. If that ends up the *same* as the input
filename, change the output filename to "nasm.out".
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
BR 3392527: make sure that all command-line specified preprocessing
directives are processed after the system-generated ones. In
particular __OUTPUT_FORMAT__ was generated after command line pass 2,
at which point -p, -d, -u, --pragma and --before had already been
processed.
There is no reason to split up defined_macros() anymore: the right
place to execute it is simply between command line passes 1 and 2. We
can also set dfmt here, which lets us define a __DEBUG_FORMAT__ macro
as well.
Finally move some options that have no business being processed in
pass 2 to pass 1.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
There are a number of places still where we test text
data which is potentially may be an empty string. This
is known to happen on fuzzer input but usually doesn't
take place in regular valid programs. Surely we need
to revisit preprocessor code for this kind of errors.
https://bugzilla.nasm.us/show_bug.cgi?id=3392525
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
A fuzzer revealed a problem in preproc code.
https://bugzilla.nasm.us/show_bug.cgi?id=3392521
Reported-by: ganshuitao <ganshuitao@gmail.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
All include paths to nasm must already have a trailing separator
prefix which is uncommon among tools. Change to using nasm_catfile
which gives a more normal behaviour.
https://bugzilla.nasm.us/show_bug.cgi?id=3392205
Signed-off-by: night199uk <night199uk@hermitcrabslab.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
So we can test for out of bound access and make
helpers safe to use.
https://bugzilla.nasm.us/show_bug.cgi?id=3392447
Reported-by: Jun <jxx13@psu.edu>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
On specially crafetd malformed input file the params
might be zapped (say due to invalid syntax) so we might
access out of bound having nil dereference in best case.
Note the later code in this helper uses tok_isnt_ helper
which already has similar check.
https://bugzilla.nasm.us/show_bug.cgi?id=3392518
Reported-by: Jordan Zebor <j.zebor@f5.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
We should check for bounds when accessing nasm_reg_flags.
Seems this bug was for long time already.
https://bugzilla.nasm.us/show_bug.cgi?id=3392516
Reported-by: Jordan Zebor <j.zebor@f5.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
We already catched a case where we've missed
test for non nil label and in result got sigsegv,
lets rather panic next time.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Unlike the relative relocations, OUT_ADDRESS had ignored the adjustments
made by add_reloc(), and writes the offset of the target symbol in the
target section.
Based-on-code-from: zenith432 <zenith432@users.sourceforge.net>
Signed-off-by: Chang S. Bae <changseok.bae@gmail.com>
If the target symbol is in the same file, add_reloc() emits an
internal reloc for the target section, and the offset written
is the offset in the target section. If the target symbol is
external, its offset is zero (or an explicit addend), and
add_reloc() emits an external reloc for the symbol.
Based-on-code-from: zenith432 <zenith432@users.sourceforge.net>
Signed-off-by: Chang S. Bae <changseok.bae@gmail.com>
The (fake) section for absolute symbols is not in the linked list. So,
when the section is not found from the index, now it simply points to
the special section.
Based-on-code-from: zenith432 <zenith432@users.sourceforge.net>
Signed-off-by: Chang S. Bae <changseok.bae@gmail.com>
As SUB relocation getting deprecated, reset external reference seems to
be enough. Also, print a warning message for this.
Based-on-code-from: zenith432 <zenith432@users.sourceforge.net>
Signed-off-by: Chang S. Bae <changseok.bae@gmail.com>
- Changed to search all symbols, instead of only global symbols.
- Will do immediate exits when unsupported use of WRT
- Fixed to mark (got)pcrel flag only for macho64 output. GOT is
supported only for 64-bit.
Based-on-code-from: zenith432 <zenith432@users.sourceforge.net>
Signed-off-by: Chang S. Bae <changseok.bae@gmail.com>
It seems like the relocation for the relative reference
to absolute addresses only cares external reference info.
Instead of exiting, reset the external reference flag.
Based-on-code-from: zenith432 <zenith432@users.sourceforge.net>
Signed-off-by: Chang S. Bae <changseok.bae@gmail.com>
The special segment may need this information for future fix-ups.
Based-on-code-from: zenith432 <zenith432@users.sourceforge.net>
Signed-off-by: Chang S. Bae <changseok.bae@gmail.com>
