Correctly generate references between sections. The previous
version would work correctly as long as all relative references
came from the first section, which is usually __TEXT,__text and
so it usually worked.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
For 64 bits, a BRANCH reloc is sometimes needed to fix up PIC
problems. Make a best effort at generating BRANCH relocs just as
we make a best effort at distinguishing GOTLOAD from GOT.
This needs to be replaced with information from the assembler to
the backend.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
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>
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>
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>
Allow the backend to specify that an output format is either text or
binary. For future uses, define this as a flag word so we can define
other flags in the future if it would make sense.
Currently, the ieee and dbg formats are text; all the others are
binary.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Received authorization from Apple to change the license of outmacho.c
to the 2-clause BSD license. Thanks!
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add new copyright headers to the new output modules. As far as I
know, the only module which we still don't have a green light to
release under 2-BSD is outmacho.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Move backend-specific code into the output/ directory, and make the
null debugging backend a separate file (it certainly isn't needed for
ndisasm...)
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
We have a number of all-zero buffers in the code. Put a single
all-zero buffer in nasmlib.c. Additionally, add fwritezero()
which can be used to write an arbitrary number of all-zero bytes;
this prevents the situation where the all-zero buffer is simply
too small.
Several projects have taken to using .text to store read-only data
when building on Mac OS X due to crashes in SSE code from the .rodata
section being mis-aligned. It seems there was a misunderstanding about
how ld/ld64 handles section alignment in outmacho.c so I wrote a patch
to fix it. I tested it against x264 git, modified it to use ".rodata
align=16" for the data section and use movdqa instructions (guaranteed
to crash when built with unpatched nasm) and it passed all tests in
its checkasm tool.
If you want more data I can provide, but it's late and I've had a
couple glasses of mulled wine :)
-DrD-
Add a common file, outlib.c, for output formats. Add the function
realsize() instead of open-coded variants in almost every backend.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Move the handling of "extra" macros (i.e. output format macros) into
the macros.pl mechanism. This allows us to change the format of the
internal macro store in the future - e.g. to a single byte store
without redundant pointers.
Also, stop using indicies into a long array when there is no good
reason to not just use different arrays.
Address data is always int64_t even if the size itself is smaller;
this was broken on bigendian hosts (still need testing!)
Create simple "write sized object" macros.
Fix alignment handling in the Mach-O format. The patch is from the
bug report, mangled to apply to the current source base. I have no
way to test this, so I'm going to have to assume it's correct.
Don't combine type and size into a single argument; *every* backend
immediately breaks them apart, so it's really just a huge waste of
effort. Additionally, it avoids using short immediates in the
resulting code, which is a bad thing.
OpenWatcom doesn't like 64-bit switch arguments; the change to 64-bit
type arguments caused that to happen in outmacho.c. Hack around it
for now; however, realistically speaking the whole bit stealing thing
is probably a bad idea, especially since virtually all CPUs handle
short immediates better than long ones.
Concentrate compiler dependencies to compiler.h; make sure compiler.h
is included first in every .c file (since some prototypes may depend
on the presence of feature request macros.)
Actually use the conditional inclusion of various functions (totally
broken in previous releases.)
Minor fixes to make it possible to compile with MS Visual C++ 2005.
Unfortunately, MSVC++ is not fully C99 compliant; in particular, it
doesn't handle interspersed declarations and other code. Furthermore,
it chokes on some expressions in outelf64.c, which fortunately can be
easily substituted with simpler expressions.
Move anything compiler-specific to "compiler.h".
There was an unguarded use of __attribute__(()) in outmacho.c; also
require gcc 4+ for __builtin_ctlz(). Speed up the open-coded version, too.
