The web site currently assumes that the release history is always in
appendix C. Humor it for now, besides, it doesn't really make sense
for the huge machine-generated instruction list to be anywhere but the
end.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
If a list of index entries is so long that the whole list can't fit
onto a single page, we *have* to break it. Treat the hanging-comma
line as a potential widow, but allow column breaks elsewhere in the
list.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
RDOFF has been deprecated as it has unfixable problems, and has been
announced that it will be killed off in NASM 2.16.
This deletes it once and for all.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
This commit adds a check to see if the macro that we want to unmacro exists.
A previous commit, introduced a check to see if the unmacro was undefining a macro being expanded, but that same check included a null pointer dereference if the macro to undefine did not exist.
The following code reproduced the issue:
```asm
%macro baz 0
%unmacro F 0
%endmacro
baz
```
Compile with:
```shell
$ nasm -f elf64 -g -FDWARF -o tmp.o -werror file.asm
```
[hpa: adjusted code to match NASM style]
Fixes bug 3392761
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The FP16 patch had a case of bit overlap. Clean up the handling of
broadcast flags a little in the process.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
This reverts commit 8fcc785f95.
This patch causes test a32offs.asm, and in general *any* use of the
"bits" macro, to totally fail.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
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 adf7507e29.
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>
