Without the limit, the while loop opens to semi-infinite
that will exhaustively consume the heap space. Also, the
index value gets into the garbage.
https://bugzilla.nasm.us/show_bug.cgi?id=3392474
Reported-by : Dongliang Mu <mudongliangabcd@gmail.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Without relocation, the linker may do erroneous dead strip.
For the relocation, the conversion of addresses to RAWDATA
should be avoided for Mach-O.
https://bugzilla.nasm.us/show_bug.cgi?id=3392469
Reported-by: Andrew Fish <afish@apple.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Even though the size is set to 64-bit, actual value can be
in 32-bit range. In that case, the use of such absolute
address is prevented.
The side effect of 58d2ab17 is resolved.
https://bugzilla.nasm.us/show_bug.cgi?id=3392468
Reported-by: Richard Russell <rtrussell@gmail.com>
Reported-by: Michael Petch <mpetch@capp-sysware.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Windows Store and Xbox One apps need to pass WACK, the Windows App
Certification Kit, and part of that process involves a tool named
BinScope that checks the debug info of all object files making up
the final executable against a list of minimum versions.
These minimum versions get increased periodically as new SDKs and
compilers are released. In a patch 2 years ago, I made NASM
pretend it was MASM and output a then-current MASM version number.
Well, the minimum version number has increased again, and
periodically hardcoding a new random MASM version to keep BinScope
happy doesn't seem like the way to go.
It turns out that BinScope does not impose any minimum version
requirements on object files listing a source language BinScope
doesn't know about.
I have no idea how to officially request a new CodeView language
ID (or whether there even is a way to do so for someone outside
MS). But experimentally, using 'N' (0x4e) for NASM seems to be
working just fine and is far away from the range of currently
allocated language IDs (which stop at 0x10).
Long story short, make NASM emit a source language ID of 0x4e,
with the actual NASM version in the version number fields.
BinScope is happy to accept that, and since the language ID field
is purely an informational field in an optional debug info record
that (as far as I can tell) is not used for anything else, this
seems reasonably safe and unlikely to cause trouble.
Signed-off-by: Fabian Giesen <fabiang@radgametools.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
This allows to mark global symbols as private external.
Similar to visibility hidden in ELF output.
Signed-off-by: Matthieu Darbois <mayeut@users.noreply.github.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
These modules need a reference to input filename.
For example elf put into symbol table
| SYMBOL TABLE:
| 0000000000000000 l df *ABS* 0000000000000000 sha-64.asm
Otherwise this become empty string.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Apparently OS/2 really wants \ as path separators, and that is really
the main target for OpenWatcom these days, so change the path
separator in this Makefile. For building on Linux we'd be better off
with a GNU Makefile anyway, but what is the point, really...
Reported-by: Andy Willis <abwillis1@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Some older versions of gcc (gcc 4.2.1 at least) produce a warning,
promoted to error, on C99 inlines. Do some work to figure out if we
need to fall back to GNU inline syntax.
Fix some issues with GNU inline syntax.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Make it possible to generate variants of RET(F) with explicit operand
size specified without having to use o16/o32/o64.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
It not only reads static variable but writes it back as well.
https://bugzilla.nasm.us/show_bug.cgi?id=3392461
Reported-by: Michael Šimáček <msimacek@redhat.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
The rarely used 64-bit absolute load instruction (what gas calls
movabsq) needs to be declared ABS if we are in relative mode, which is
normally the case.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
There are some gotchas in how immediates and pointers are loaded in
64-bit mode and how they interact with optimization. Document those
cases.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Bullet points are considered paragraphs, so our documentation compiler
require an empty line between them.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Automatically assign values to the instruction flags; we ended up with
a case where pushing flags into the next dword caused comparison
failures due to other places in the code explicitly comparing
field[3].
This creates necessary defines for this not to happen; it also cleans
up a fair bit of the iflag code.
This resolves BR 3392454.
Reported-by: Thomasz Kantecki <tomasz.kantecki@intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
In commit a8f3698cf31a9379cf85416c6cb40c3340e90adb
the iflag_cmp_cpu_level escaped updating. Fix it.
Reported-by: Tomasz Kantecki <tomasz.kantecki@intel.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
