Correct the handling of GOT relocations, as they need a symbol
reference. Add handling of TLVP relocations; it is unclear to me
if non-local relocations in TLVP space is permitted.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
For the mapping of .rodata to __TEXT,__const in the absence of
relocations, it would help if we changed the segment name *before* we
emit that part of the load command.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Sanitize the handling of sections in outmacho somewhat. This should
bring further performance improvements.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Slightly simplify the handling of segment number allocation.
If we are in absolute space, never push a segalign down to the backend.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
If we specify .rodata as opposed to the explicit __DATA,__const, and
we end up with no relocations, change it to __TEXT,__const per the
Mach-O ABI. However, it is generally better for the programmer to
explicitly specify the items that should go into __TEXT,__const as
otherwise a single relocatable item will force the whole thing into
__DATA.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Allow specifying sections with arbitary MachO segment and section
names, as opposed to having a fixed list of supported sections
(especially __DATA,__const is wrong in some cases.) Furthermore,
we do a completely unnecessary lookup of the bss section *for every
call to macho_output()* which is just plain crazy.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Exceeding MAX_SECT is not a warning, it is a fatal error. However,
there is no point to test for it until we already process all the
sections.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
When we clear the ext bit, creating section-relative relocations,
the resulting value is computed somewhat differently; we need to
adjust for that.
TODO: Need to make sure we do the right thing for ALL relocations.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
configure.in: Add the -Werror flags as the last thing. Otherwise, with
development versions of autoconf, all AC_CHECK_FUNCS calls fails with:
conftest.c:49: error: function declaration isn't a prototype
conftest.c:49: warning: conflicting types for built-in function 'strcspn'
Signed-off-by: Ozkan Sezer <sezero@users.sourceforge.net>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
We generate section-relative relocations for local symbols for all
the other output formats, and we should do the same for MachO;
this was done in MachO-32 but not in MachO-64, presumably because
the MachO spec implies that such relocations shouldn't exist in
64-bit code. They are indeed rare, but that is a programmer's
decision, and the spec is clear that they are legal.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
When converting an address to RAWDATA we have to copy the address size
into the size variable, as the size variable may be negative.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
The name for the macho32 output format was incorrectly set to
macho64, which means neither macho32 nor macho64 worked correctly.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Allow section alignment to be declared more than once, with different
values. The strictest alignment value via either a section or
sectalign directive becomes the controlling parameter.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Merge the two Mach-O backends for cleanliness and maintainability.
This should also make the recent fixes to MachO-64 available in
MachO-32.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
If realpath(..., NULL) doesn't work, we have to allocate a buffer
blindly. Use the value returned from pathconf() in preference from
compile-time constants.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
When the macho64 backend was forked, instead of fixing variables which
ought to have been static all along, the porter added a -64 suffix to
prevent namespace conflict. Fix it by making those variables static.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
First of all we printed the wrong error message, and second of all we
need to set the segments to NO_SEG before passing them to the output
format generator.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Handle the case of oversized (larger than permitted by the output
format) relative relocations. Relative relocations are always signed,
and quite likely to actually have the sign bits set, so zero-extending
them is not an option. Fortunately oversized relative relocations
are rare, as no CPU instruction support 64-bit relative addresses.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
This fixes the macho64 output. However, macho32 has the same problems and the
code either needs to be backported or, better yet, unified.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Fix an array that was way too small resulting in memory overwrite
errors, and free a few more dynamic data structures.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
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>
