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>
Looks like -Werror=missing-declarations revealed problem in
configure: the "inline" support has not been detected properly
leading to problem in building procedure.
Lets move AC_C_INLINE and etc to be tested before gcc flags.
Reported-by: NAKAI Yuta <nak5124@live.jp>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
The sequence | 0x0F 0x1B 0x75 | get matched into
one of BNDx instruction which register value 6
which is of course out of possible BND registers
implemented in hardware at the moment leading to
nil dereference.
Instead lets use a macro in whichreg() helper
which would test the registers bounds and force
the caller to try another template if register is
out of range. In the case above it simply means
ndisasm instead of crashing outputs
| 00000000 0F db 0x0f
| 00000001 1B db 0x1b
| 00000002 75 db 0x75
http://bugzilla.nasm.us/show_bug.cgi?id=3392289
Reported-by: Hanno Boeck <hanno@hboeck.de>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
A few changes here
- fix in VMOVNTPS 256 bit encoding
- fix nil dereference in memory parsing code
and access to uninitialized space when handling
strings
- fix processing of -MD option, the commit 599a982
was fixing one issue but occasionally broke visible
command line api, leading to (for example) syslinux
can't be built with previous version.
There are some more bugs which are to be addressed
but due to fix of -MD option we need to release update.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
