case PP_ENDM:
case PP_ENDMACRO:
if (!(defining && defining->name)) {
nasm_nonfatal("`%s': not defining a macro", tok_text(tline));
goto done;
}
mmhead = (MMacro **) hash_findi_add(&mmacros, defining->name);
defining->next = *mmhead;
*mmhead = defining;
defining = NULL;
break;
The variable: mmacros has not been released, which will cause a memory
leak. Repair cve-2021-33450 cve-2021-33452 synchronously
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add support for AVX512-FP16 instructions and the associated
handling. Allow "mapN" syntax as well as "mN" syntax to match the
documentation.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
free() and nasm_free() are required to be compatible (as we may end up
having memory allocated on the heap by the C library), but that
doesn't mean we shouldn't use it whereever possible to allow for
better debugging.
Fixes: https://bugzilla.nasm.us/show_bug.cgi?id=3392804
Reported-by: C. Masloch <pushbx@ulukai.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
An empty %{} becomes % which is simply the arithmetic
operator. Although that is consistent, it might be surprising for
users, to issue a warning.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
%[] amounts to an empty token; this needs to be handled specially so
that it gets properly dropped.
Fixes: https://bugzilla.nasm.us/show_bug.cgi?id=3392806
Reported-by: C. Masloch <pushbx@ulukai.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
while (nbs--) { ... } ends with nbs == -1. Rather than a minimal fix,
introduce mempset() to make these kinds of errors less likely in the
future.
Fixes: https://bugzilla.nasm.us/show_bug.cgi?id=3392815
Reported-by: <13579and24680@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The VCVTNEPS2BF16 instruction was incorrectly specified as
VCVTNE2S2BF16. Fortunately, the correct opcode for the latter was
specified first, so it would emit the correct result when that
instruction was specified.
Fixes: https://bugzilla.nasm.us/show_bug.cgi?id=3392821
Reported-by: Agner <agner@agner.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
There are no use cases for of RELA on i386, and the intent has always been
that efmt->rel_size would be the size of the desired relocation
section type. Rename it from rel_size to relsize to make it more
obvious that it matches efmt->reltype rather than SHT_REL, and delete
efmt->rela_size to keep it from being misused again.
This should avoid a repeat of:
https://bugzilla.nasm.us/show_bug.cgi?id=3392807
fixed in adf7507e29f95b4e708275e0c1cb81aea3b12a6b.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
There is no documentation of the `%unimacro` directive.
This is particularly confusing when you’re trying to remove a macro
that has previously been defined with the `%imacro` directive.
The RDOFF tools are fundamentally broken to the core: they are
defining headers which contain misaligned structure members, which
cause the compiler to add padding, breaking the format.
This is just a build fix; remove RDOFF in 2.16.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
istruc currently does not work very well with passing local labels to
"at" macro, as the labels are inserted literally. E.g. considering the
example from test/struc.asm:
struc teststruc1
.long: resd 1
.word: resw 1
.byte: resb 1
.str: resb 32
endstruc
; ...
istruc teststruc1
at .word, db 5
iend
if one were to put a global label before istruc to refer to its
instance, the code would fail to compile, due to ".word" being unknown
in that scope. Of course one could then use full form after "at", i.e.
"teststruc1.word", but this seems rather tedious.
This also makes istruc use with local labels fail for anything but the
last declared struc.
The change automatically prepends struc name to the label if the label
given to "at" starts with a dot.
Signed-off-by: Sławomir Bocheński <lkslawek@gmail.com>
i386 should use REL relocation in DWARF sections with addend stored at
the relocation offset. This fixes
https://bugzilla.nasm.us/show_bug.cgi?id=3392807
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
I'm dealing with a FreeBSD-derived embedded target that ends up
showing such symbols (which is mainly NASM struct definitions)
in backtraces after calling NULL function pointers, since these
symbols _are_ technically covering bytes around address zero.
Needless to say, this is extremely confusing and generates
nonsensical bug reports. (Essentially, random unrelated crashes
get cross-referenced to a random ASM struct, whatever the linker
picked for address 0).
These symbols are already a bit strange to begin with (they're
purely an artifact of how NASM happens to implement structs),
leaving their sizes at 0 seems reasonable.
Signed-off-by: Fabian Giesen <fabian.giesen@epicgames.com>
Before this patch, COFF output always contained the first 18 bytes of the
input filename. This breaks reproducibility and may also leak sensitive
data to objects (esp. with input filenames with absolute paths.)
This patch makes this output respect the --reproducible option, and omits
the input filename from the COFF output, when set.
Usage was removed in b6ba0a23f975844f412c2b1afc864413719b6d48
Fixes:
output/outcoff.c:302:28: warning: unused function 'coff_alignment' [-Wunused-function]
static inline unsigned int coff_alignment(uint32_t flags)
^
The size calculation done in len_extops() (called by insn_size()) for
EOT_DB_RESERVE (i.e. uninitialized storage "?" token) does not take
into account the element size (e->elem), thus calculating a wrong
size for any Dx larger than DB (DW, DQ, etc).
The bug is silent, but it makes NASM error out if a "Dx ?" (larger
than DB) is followed by any label because the label offset gets
mismatched in the final code generation stage:
$ cat test.asm
[section .bss]
DW ?
x:
$ nasm test.asm
test.asm:3: error: label `x' changed during code generation [-w+error=label-redef-late]
See also: https://stackoverflow.com/q/70012188/3889449
Signed-off-by: Marco Bonelli <marco@mebeim.net>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Andrew reported that we may access unitialized memory
> SUMMARY: MemorySanitizer: use-of-uninitialized-value nasm/asm/parser.c:982:41 in parse_line
It turns out that in case of malformed data the expression is terminator
itself so we should not "lookup ahead" for next one. Thus test for first
expression initially and if test passes check for terminator.
Reported-by: Andrew Bao <xiaobaozidi@gmail.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
