-Werror now trips on implicit fallthroughs. There is also at least one
that probably should not be, although it appears to be harmless.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
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>