note, preinit_array, init_array, and fini_array are ELF section types
that can matter to the assembly programmer.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Dead code elimination in ELF uses separate ELF sections for every
functions or data items that may be garbage collected. This can end up
being more than 32,633 sections which, when the ELF internal and
relocation sections are added in, can exceed the legacy ELF maximum of
65,279 sections.
Newer versions of the ELF specification has added support for much
larger number of sections by putting a place holder value (usually
SHN_XINDEX == 0xffff, but 0 in some cases) into fields where the
section index is a 16-bit value, and storing the full value in a
diffent place: the program header uses entries in section header 0,
the symbol table uses an auxiliary segment with the additional
indicies; the section header did not need it as the sh_link field is
already 32 (or 64) bits long.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Use a hash table to look up sections by name, and an RAA to look up
sections by index; thus remove O(n) searches. This becomes important
since ELF uses sections for dead code elimination.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Add support for the "merge" attribute in ELF, along with the
associated "strings" and size specifier attributes.
Fix a few places where we used "int", but a larger type really ought
to have been used.
Be a bit more lax about respecifying attributes. For example, align=
can be respecified; the highest resulting value is used.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The prefix ERR_WARN_ is unnecessarily long and may be a disincentive
to create new warning categories. Change it to WARN_*, it is still
plenty distinctive.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
External symbols are defined via deflabel(), but deflabel() is not
called until pass0 == 1. Until that happens, segbase has no way to
know what the proper segment base of the segment actually is.
Thus, testing for pass0 == 0 will always fail for a forward reference;
correct the test to test for pass0 < 2, i.e. the assert should fail
only for the final code-generation pass.
Reported-by: <stsp@list.ru>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Unlike the relative relocations, OUT_ADDRESS had ignored the adjustments
made by add_reloc(), and writes the offset of the target symbol in the
target section.
Based-on-code-from: zenith432 <zenith432@users.sourceforge.net>
Signed-off-by: Chang S. Bae <changseok.bae@gmail.com>
If the target symbol is in the same file, add_reloc() emits an
internal reloc for the target section, and the offset written
is the offset in the target section. If the target symbol is
external, its offset is zero (or an explicit addend), and
add_reloc() emits an external reloc for the symbol.
Based-on-code-from: zenith432 <zenith432@users.sourceforge.net>
Signed-off-by: Chang S. Bae <changseok.bae@gmail.com>
The (fake) section for absolute symbols is not in the linked list. So,
when the section is not found from the index, now it simply points to
the special section.
Based-on-code-from: zenith432 <zenith432@users.sourceforge.net>
Signed-off-by: Chang S. Bae <changseok.bae@gmail.com>
As SUB relocation getting deprecated, reset external reference seems to
be enough. Also, print a warning message for this.
Based-on-code-from: zenith432 <zenith432@users.sourceforge.net>
Signed-off-by: Chang S. Bae <changseok.bae@gmail.com>
- Changed to search all symbols, instead of only global symbols.
- Will do immediate exits when unsupported use of WRT
- Fixed to mark (got)pcrel flag only for macho64 output. GOT is
supported only for 64-bit.
Based-on-code-from: zenith432 <zenith432@users.sourceforge.net>
Signed-off-by: Chang S. Bae <changseok.bae@gmail.com>
It seems like the relocation for the relative reference
to absolute addresses only cares external reference info.
Instead of exiting, reset the external reference flag.
Based-on-code-from: zenith432 <zenith432@users.sourceforge.net>
Signed-off-by: Chang S. Bae <changseok.bae@gmail.com>
The special segment may need this information for future fix-ups.
Based-on-code-from: zenith432 <zenith432@users.sourceforge.net>
Signed-off-by: Chang S. Bae <changseok.bae@gmail.com>
Recent labeling mechanism changes seem to bring the case,
where segment() procedure is called when the segment list
is empty. Now, it will simply check and initalize the
segment list.
Reported-by: Ozkan Sezer <sezeroz@gmail.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Previously, X86_64_RELOC_BRANCH is only set for external
relocations. Internal relocation also needs this type to be
set, instead of the default (X86_64_RELOC_SIGNED) or
anything.
Reported-by: <zenith432@users.sourceforge.net>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
The jump-match optimization tends to remove labels. When the
"subsections_via_symbols" pragma is declared, all the labels
should be emitted. Disabling the optimization (only) makes
the pragma effective.
It might be cleaner to extend the OFMT interface to support
callback function. In this case, the reconfiguration can be
done through the callback interface, rather than direct
access to the global variable.
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
We don't want to lose the offset into the parent section when we
create a subsection, at least not for the MachO backend which is
currently the only user of subsections. Allow ofmt->herelabel() to set
a flag to copy the section offset from the previous section.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Make all limit counters 64 bits, in case someone really has a usage
for an insanely large program. The globallines limit was omitted, add
it to the list of configurable limits.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Encoding magic (in this case, subsection number) by bitfields in the
segment index has several problems:
1. It limits the number of *external symbols* as well as
segments/subsections.
2. It is inefficient for the assembler (creates a very large RAA).
This is also a really good opportunity for removing linear lookups in
the MachO backend. We now use an RAA to do look up segment by index,
and a hash table to look up segment by name. Subsections are simply
handled by allocating a new index using seg_alloc() but still point it
to the same section structure in the index RAA.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Allow the subsection to store a subsection value directly in the
label, rather than having to do strange encoding hacks.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
OFMT_KEEP_ADDR seems to not work properly. Now when we have proper
subsections, there is no need for that anymore.
This reverts commit 69ed82447a.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
In order to support Mach-O better, add support for subsections, as
used by Mach-O "subsections_via_symbols". We also want to add
infrastructure to support this by downcalling to the backend to
indicate if a new subsection is needed.
Currently this supports a maximum of 2^14 subsections per section for
Mach-O; this can be addressed by adding a level of indirection (or
cleaning up the handling of sections so we have an actual data
structure.)
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
MachO has this odd thing called "subsections via symbols", by which a
symbol can magically start what effectively is a new section. To
support this, add support for a calldown into the backend when a new
symbol is defined *at the current output location*, and allow it to
switch the current segment.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Without relocation, the linker may do erroneous dead strip.
For the relocation, the conversion of addresses to RAWDATA
should be avoided for Mach-O.
https://bugzilla.nasm.us/show_bug.cgi?id=3392469
Reported-by: Andrew Fish <afish@apple.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Even though the size is set to 64-bit, actual value can be
in 32-bit range. In that case, the use of such absolute
address is prevented.
The side effect of 58d2ab17 is resolved.
https://bugzilla.nasm.us/show_bug.cgi?id=3392468
Reported-by: Richard Russell <rtrussell@gmail.com>
Reported-by: Michael Petch <mpetch@capp-sysware.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Windows Store and Xbox One apps need to pass WACK, the Windows App
Certification Kit, and part of that process involves a tool named
BinScope that checks the debug info of all object files making up
the final executable against a list of minimum versions.
These minimum versions get increased periodically as new SDKs and
compilers are released. In a patch 2 years ago, I made NASM
pretend it was MASM and output a then-current MASM version number.
Well, the minimum version number has increased again, and
periodically hardcoding a new random MASM version to keep BinScope
happy doesn't seem like the way to go.
It turns out that BinScope does not impose any minimum version
requirements on object files listing a source language BinScope
doesn't know about.
I have no idea how to officially request a new CodeView language
ID (or whether there even is a way to do so for someone outside
MS). But experimentally, using 'N' (0x4e) for NASM seems to be
working just fine and is far away from the range of currently
allocated language IDs (which stop at 0x10).
Long story short, make NASM emit a source language ID of 0x4e,
with the actual NASM version in the version number fields.
BinScope is happy to accept that, and since the language ID field
is purely an informational field in an optional debug info record
that (as far as I can tell) is not used for anything else, this
seems reasonably safe and unlikely to cause trouble.
Signed-off-by: Fabian Giesen <fabiang@radgametools.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
This allows to mark global symbols as private external.
Similar to visibility hidden in ELF output.
Signed-off-by: Matthieu Darbois <mayeut@users.noreply.github.com>
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
These modules need a reference to input filename.
For example elf put into symbol table
| SYMBOL TABLE:
| 0000000000000000 l df *ABS* 0000000000000000 sha-64.asm
Otherwise this become empty string.
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
Get rid of remaining dependencies on FILENAME_MAX, which ought to have
been removed a long time ago.
Remove ofmt->filename(); all implementations pretty much do the same
thing and there is absolutely no reason to duplicate that
functionality all over the place.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
The DWARF spec specifies that the .debug_abbrev section always should
end with a null byte. Existing tools don't seem to care, but some
issue a warning, and it is invalid according to spec.
Reported-by: Darren Sylvain <sylvaindarren@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Support 16-character section names, and support the debug section
flag.
Reported-by: Andrey Timofeyev <timofeyev@bk.ru>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
For many (most?) targets these will be very small functions, so inline
them. However, just in case make these external library functions.
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Some OMF toolchain can make use of file dependency information
embedded in the object files. As implemented here, we don't try to
absolutize the filenames, as that prevents moving around trees and is
OS-dependent.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Do all the generation and conversion of the compiler timestamp in one
place and make it available to modules.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
It seems that the MachO64 linker really doesn't like segment-relative
relocations under certain circumstances, so force relocations to be converted
to "external" (symbol-relative); error out if no symbol is available
(if this is a problem, we can consider inserting a synthetic symbol if
necessary.)
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
