In BR 3392539, the error:
helloW.s:18: error: label `rurt' changed during code generation
[-w+error=label-redef-late]
... occurs a number of times after we have already issued an
error. This is because the erroring instruction computes to a
different size during code generation; this causes each subsequent
label to cause a phase error.
The phase error simply doesn't make much sense to report: if we are
already committed to erroring out, it is more likely an error cascade
rather than an error in its own right, so just suppress it in that
case.
Reported-by: <russvz@comcast.net>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
In list_emit we walk over listerr_head freeing the list,
but the head pointer remain carrying old value. Need
to clean it up once traverse is done to not access
already freed memory later.
https://bugzilla.nasm.us/show_bug.cgi?id=3392538
Reported-by: russvz@comcast.net
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Test case from bug 3392538 for double free in the listing module.
This is the test case only, not a fix.
Reported-by: <russyz@comcast.net>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
AMD documents this instruction with an rax operand. The error behavior
implies this is an address-size-sensitive instruction. Add support for
specifying the explicit operand, but consistent with normal ndisasm
behavior, don't disassemble the implicit operand.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The -Ov option is useful but was undocumented.
Add an initialization to keep gcc from complaining at optimization
level -Og.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
For debugging preprocessed code, it is useful to be able to ignore
%line directives rather than having to filter them out externally.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
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>
ERR_HERE is used to mark messages of the form "... here" so that we
can emit sane output to the list file with filename and line number,
instead of a nonsensical "here" which could point almost anywhere.
This patch contains some changes from the one in the master branch to
make the code cleaner.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The differences between nasm_verror_{gnu,vc} are a short handful of
strings, so unify them. Remove some additional ERR_NOFILE that are not
necessary.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
If we redefine consistently, make it a suppressed-by-default warning.
If we end up doing the define on pass 2, promote that to a
default-error warning; using a default-error warning allows the user
to demote it should they so wish.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Requested-by: C. Masloch <pushbx@38.de>
We may produce an arbitrary number of error messages on a single line;
include all of them in the list file.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
This allows us to do soft-migration of warnings to errors; they will
now be nonfatal errors by default, but gives the user the option to
demote them.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Putting WARN_OTHER at the end of the list creates a number of
advantages and simplifications:
1. It is more user friendly! It is far more of a logical location for
the default case to be at the end of the printed list.
2. The value 0 can be used in a number of places to indicate a
non-suppressible event. By having warning_state[0] always contain
WARN_ST_ENABLED, we can always do the table lookup, even.
3. It means non-warnings (except fatal/panic) can now be conditioned
on warning states. In those cases, WARN_*, including WARN_OTHER,
can be added to the mask for any category. This is especially
useful for notes.
The only downside is that we have to explicitly detect the case where
we have ERR_WARNING but no WARN_ flag. This is a trivial test.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Shifting negative values is undefined in standard C, but we have tons
of dependencies that signed arithmetic is 2's-complement in the code
anyway, and on gcc-like compilers we pass the -fwrapv option to
indicate exactly that. Therefore, this is not a valid warning in our
case and should be suppressed.
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.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
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>
