Instead of ~1/4 the range we can use ~1/3 the range for better
distance. It is possible that using ~1/2 - 1 might be even better,
but this is a trivial tweak.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
If BUFSIZ exists and is bigger than the default ZERO_BUF_SIZE, expand
ZERO_BUF_SIZE so we don't end up unnecessarily double buffering in the
stdio library.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Undefine __STRICT_ANSI__ for djgpp; it removes the prototypes for
non-ANSI functions which is not at all what this symbol is intended
for.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Remove the #if 0 for canonicalize_file_name(). This was added to
test the realpath() code, and inadvertently left in.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Add the option --allow-64-bit to permit the generation of 64-bit code
even for a 16/32-bit output format.
Using NASM to do some boot strapping code and ran into trouble when
trying to emit a few 64-bit instructions in the OMF object file doing
the mode switching. While I can see how the "error: obj output format
does not support 64-bit code" message can be a useful reality check
for application programmers, it prevents low-level programmers from
doing what they want. It if was just a harmless warning, it wouldn't
be so bad, but it turns BITS 64 into BITS 16. The main trick to mixing
64-bit code into OMF and other 32-bit output formats is to avoid
64-bit sized fixups, which normally isn't too hard.
[hpa: shortened the option name to --allow-64-bit, minor code cleanups]
Signed-off-by: Knut St. Osmundsen <bird-nasm@anduin.net>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The previous commit contained unnecessary dependencies for realpath.c
so run make alldeps to remove those.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Try harder to nasm_realpath() to be as portable as possible. Move it
to a separate file since it has gotten complex enough that it is
cleaner that way.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Codeview is a debug format for win32/win64 PE/COFF files. It adds two sections,
.debug$S (symbols) and .debug$T (types), to the generated object file. These
sections are then used by the linker to generate a PDB file which can be used
by various debuggers (WinDbg, Visual Studio, etc).
Signed-off-by: Jim Kukunas <james.t.kukunas@linux.intel.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
This implementation was written by Colin Plumb and
is in the public domain.
I've updated it to use stdint.h and the standard C types rather than
sys/types.h for portability.
Signed-off-by: Jim Kukunas <james.t.kukunas@linux.intel.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Converts a relative pathname to an absolute pathname.
Signed-off-by: Jim Kukunas <james.t.kukunas@linux.intel.com>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
When running in preprocess-only mode generate the equivalent of
standard alignment using nops. This at the very least allows some
kind of reasonable output and allows for dependency generation to
proceed; the only way to *really* address this problem is to move
alignment generation into the assembler proper; this would also allow
the align/alignb distinction to be removed and handle padding with
instructions which are more than one byte.
This should resolve bug 3392319.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
As been pointed by @hpa evex is pretty fine in ia-32.
Quoting Peter
| This is wrong, though; EVEX is permitted in 32-bit mode just as VEX is.
| The key thing is that bits [7:5] have to be 1 in 32-bit mode. It is
| unclear what happens if these bits are 110 as that depends on if it is
| decoded using the modr/m decoder or not. For VEX prefixes we accept
| them as VEX in that case, which may not match the CPU.
This is a fix for commit db6ecf9b76
Reported-by: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
We're converting address value into bigendian
(on BE machine) and then continue doing arithmetics
on top, which is of course incorrect.
Instead do all operations first then convert
to BE and write it into image.
Reported-by: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
The opcode for BOUND, 62h, has a different meaning in long mode - it is the
prefix for EVEX instructions. ndisasm did not take this into account and always
tried to disassemble 62h back to an EVEX instruction.
Attached patch only permits EVEX disassembly if bitness is 64.
In 16/32 bit mode 62h will be not be a prefix and so disassemble
to BOUND.
Signed-off-by: Mark Scott <nasm@mscott.cx>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Each stabs entry is 12 bytes in size, for some reason we've
been pasing wrong attribute here in @n_value.
Signed-off-by: Mark Scott <nasm@mscott.cx>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
- Fix symbol alignment for Elf64
- Fix symbol lookup for Macho64
- Fix relocation records for Macho64
- Fix potential stack overwrite in Macho32
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.org>
Previously only the first byte was updated (since @mydata
is a an uint8_t[]).
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
The size of address migh be up to 8 bytes here
so allocate enough stack space.
http://bugzilla.nasm.us/show_bug.cgi?id=3392317
Reported-by: Kyle Brodie <kylecbrodie@gmail.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Because of 74a08cc3f we no longer need to write all
8 bytes here, revert it back as it were before
5b730a197
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
This is a a buffer on stack big enough to hold
bigger object we might need (address, number and
etc) but it's defined as an array of bytes and
we treat it as different types depending on context,
which may lead to situation where data from stack
been treated as meaningful.
In particular in commit 5b730a197 we've fixed such
problem simply using a "big" write to zeroify stack
data before use.
Lets simply zeroify this buffer explicitly to escape
such problems in future.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Whereas Unix shells automatically globs wildcard arguments, Windows leaves it
up to application. This commit fixes the build for perl implementations that
don't handle wildcards.
Signed-off-by: Jim Kukunas <james.t.kukunas@linux.intel.com>
Ensure that the int64_t offset value, which ultimately comes from an
int64_t value in gencode() (assemble.c:1906), is completely written to
the temporary buffer, instead of merely its least significant 32 bits.
Prior to this change, WRITELONG was used instead of WRITEDLONG, which
resulted in add_reloc being passed an int64_t "reloff" whose least
significant 32 bits were those from the aforementioned offset value,
and whose most significant 32 bits were stack garbage from "mydata".
This led to get_closest_section_symbol_by_offset() attempting to search
for extremely large values of "offset" among the symbols in "syms",
which meant that the last symbol with a matching section number would
always win the symbol search.
In effect, this clobbered the resultant relocation information, such
that all entries would be resolved with the same symbol.
Test output can be found here
https://www.azabani.com/patch/2/output.txt
This patch fixes
http://bugzilla.nasm.us/show_bug.cgi?id=3392306
Signed-off-by: Delan Azabani <delan@azabani.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
In case if we're looking up for a symbol and it's first
one in symbol table we might endup with error because of
using GE here (78f477b35f) ending cycle with @nearest = NULL.
http://bugzilla.nasm.us/show_bug.cgi?id=3392306
Reprted-by: Benjamin Randazzo <benjamin@linuxcrashing.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Discovered while working on ELF Tool Chain elfcopy (strip),
which originally crashed on an assert while processing
a nasm-generated ELF object.
The .symtab and .rela.text sections report 4 byte alignment,
but require 8.
As an aside, see https://sourceforge.net/p/elftoolchain/tickets/485/ for a
discussion of the ELF Tool Chain issue that this bug exposed.
With my WIP elfcopy change and nasm-assembled jccolss2-64.o from libjpeg-turbo:
% strip -o /dev/null --strip-debug jccolss2-64.o
strip: section .symtab alignment 4 increased to 8
strip: section .rela.text alignment 4 increased to 8
http://bugzilla.nasm.us/show_bug.cgi?id=3392307
Signed-off-by: Ed Maste <emaste@freebsd.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
While been preparing release I managed to write
non-number sequence into @version, which might
cause build problems. Lets fix it here and if
a moment happens -- release 2.11.09.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
- Fix section length computation in bin backend which
leaded in incorrect relocation records.
- Add a warning for numeric preprocessor definitions
passed via command line which might have unexpected
results otherwise.
- Add ability to specify a module name record in rdoff
linker with -mn option.
- Increase label length capacity up to 256 bytes in rdoff
backend for FreePascal sake, which tends to generate very
long labels for procedures.
- Fix segmentation failure when rip addressing is used
in macho64 backend.
- Fix access on out of memory when handling strings with
a single grave. We have sixed similar problem in previous
release but not all cases were covered.
- Fix NULL dereference in disassembled on BND instruction.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
@size might be negative for signed relocations but its length
is abs value. This is rather a fix for future use because at
moment we can't hit this problems but better be on a safe side.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
While we using proper @asize variable for relocation itself
we miss the fact that @size variable (which might be negative
for signed relocations since fd52c277dd) is used to calculate
section size increment.
http://bugzilla.nasm.us/show_bug.cgi?id=3392299
Reported-by: Ben de Waal <ben@dewaals.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Not sure if someone is used this but to not break
backward compatibility lets simply yield error but
don't stop processing.
http://bugzilla.nasm.us/show_bug.cgi?id=3392300
Reported-by: Dave Shields <thedaveshields@gmail.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Rationale: this is useful for projects developed entirely in high-level
language and which use NASM as a backend (compilers able to generate NASM
code are e.g. ncc or Free Pascal). With this option there is no need to have
a single assembly language file for each project with just one "module NNN"
directive — it is enough now to specify the name as an argument to ldrdf.
Signed-off-by: Yuri Zaporozhets <r_tty@yahoo.co.uk>
Rationale: this is required for, e.g., FreePascal, which tends to generate
very long labels for procedures/methods that do not fit into 64 bytes.
This change does not introduce any incompatibilities.
Signed-off-by: Yuri Zaporozhets <r_tty@yahoo.co.uk>
The posix_ prefix is reserved for POSIX, and even if there never is a
posix_mktime() defined it might be confusing for programmers familiar
with this convention.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
In commit a45febd767 only part of problem has been covered.
Need to be ready for strings like
| `a
http://bugzilla.nasm.us/show_bug.cgi?id=3392295
Reported-by: Hanno Boeck <hanno@hboeck.de>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
