Hopefully actually fix the issues with alignment this time.
Avoid a linear search of segments for each symbol emitted.
Issue an empty LC_DATA_IN_CODE command since that seems to be
expected.
With this, ffmpeg builds but still crashes on startup, which seems
very strange.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Remove the --allow-64-bits relocation, and instead make it a
suppressible warning in the case of a zero-extended relocation, and an
error in the case of a sign-extended relocation.
Relocations which can be losslessly represented in the output format
do not issue any diagnostic at all, as there is no problem in that
case.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
There is no reason to pass a constant and a string from each call
site. Move that into a separate out of line function.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
size is actually an uint64_t, and LLVM drops the abs() on the
principle that the uint64_t should always be positive. Make it
explicit that we are converting to a signed integer first, by using
abs((int)size) instead.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
A pointer to a field in a structure can never be NULL so remove
the test. There is no reason to test the field for an empty string
either, since we immediately thereafter do a strcmp().
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Apparently some BSD flavors define these macros in a system header
file; this includes MacOS X. Assume we can just #undef them without
causing any additional issues; otherwise we may need to rename them.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Fix a number of places which failed to account for padding to
alignment of section data. Also, fix confusion between aligning
section data in the linkable object code and final address alignment;
LLVM/Xcode always align section data to 4 bytes (with a comment saying
that it probably should be 8 bytes for 64-bit output) independent of the
section alignment.
This will need to be ported to the macho32 backend, as well; ideally
the two should be merged as they are really very similar and we don't
want to have these kinds of cross-porting problems.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Add a generic panic() macro which we can simply insert where an
internal error happens. Also, create a nasm_panic() function
the only purpose of which is to let the compiler know that we will
never return after a panic.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
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>
