Windows: indicate that we support multibyte character sets in file
names.
Unix: support gigantic input and output files. Might be useful
especially in the presence of the INCBIN directive.
Signed-off-by: H. Peter Anvin <hpa@linux.kernel.org>
The __TEXT segment in particular contains both code and data. The
most consistent thing is to look only at the section name, and have
the same behavior across sections.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Right now, we don't check the return value from nasm_realpath();
furthermore doing so and failing is probably not the ideal behavior.
If we can't get the full canonical path, then punt and just return
nasm_strdup() of the known path name; better than nothing.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Instead of completely useless sequential line numbers, emit line
numbers corresponding to the line numbers in the source code.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Make a point of the output format constants instead of making it
a pointer. The output format is set only once, but it is accessed
all the time.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
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>
