This tidies up some code that was manually constructing RuntimeDyld::SymbolInfo
instances from JITSymbols. It will save more mess in the future when
JITSymbol::getAddress is extended to return an Expected<TargetAddress> rather
than just a TargetAddress, since we'll be able to embed the error checking in
the conversion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271350 91177308-0d34-0410-b5e6-96231b3b80d8
when the object is from a slice of a Mach-O Universal Binary use something like
"foo.o (for architecture i386)" as part of the error message when expected.
Also fixed places in these tools that were ignoring object file errors from
MachOUniversalBinary::getAsObjectFile() when the code moved on to see if
the slice was an archive.
To do this MachOUniversalBinary::getAsObjectFile() and
MachOUniversalBinary::getObjectForArch() were changed from returning
ErrorOr<...> to Expected<...> then that was threaded up to its users.
Converting these interfaces to Expected<> from ErrorOr<> does involve
touching a number of places. To contain the changes for now the use of
errorToErrorCode() is still used in two places yet to be fully converted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271332 91177308-0d34-0410-b5e6-96231b3b80d8
Adds the method MCStreamer::EmitBinaryData, which is usually an alias
for EmitBytes. In the MCAsmStreamer case, it is overridden to emit hex
dump output like this:
.byte 0x0e, 0x00, 0x08, 0x10
.byte 0x03, 0x00, 0x00, 0x00
.byte 0x00, 0x00, 0x00, 0x00
.byte 0x00, 0x10, 0x00, 0x00
Also, when verbose asm comments are enabled, this patch prints the dump
output for each comment before its record, like this:
# ArgList (0x1000) {
# TypeLeafKind: LF_ARGLIST (0x1201)
# NumArgs: 0
# Arguments [
# ]
# }
.byte 0x06, 0x00, 0x01, 0x12
.byte 0x00, 0x00, 0x00, 0x00
This should make debugging easier and testing more convenient.
Reviewers: aaboud
Subscribers: majnemer, zturner, amccarth, aaboud, llvm-commits
Differential Revision: http://reviews.llvm.org/D20711
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271313 91177308-0d34-0410-b5e6-96231b3b80d8
The MachO export trie is a serially encoded trie keyed by symbol name. This code parses the trie and preserves the structure so that it can be dumped again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271300 91177308-0d34-0410-b5e6-96231b3b80d8
Looks like the dwarfdump fuzzer has bitrotted, update it to take into
account updates to the libobject API.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271242 91177308-0d34-0410-b5e6-96231b3b80d8
This converts remaining uses of ByteStream, which was still
left in the symbol stream and type stream, to using the new
StreamInterface zero-copy classes.
RecordIterator is finally deleted, so this is the only way left
now. Additionally, more error checking is added when iterating
the various streams.
With this, the transition to zero copy pdb access is complete.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271101 91177308-0d34-0410-b5e6-96231b3b80d8
clang-tidy's performance-unnecessary-copy-initialization with some manual
fixes. No functional changes intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270988 91177308-0d34-0410-b5e6-96231b3b80d8
Fix: updated clang code which was not updated by mistake.
Original commit message:
[llvm-mc] - Teach llvm-mc to generate zlib styled compression sections.
This patch is strongly based on previously reverted D20331.
(because of gnuutils < 2.26 does not support compressed debug sections in non zlib-gnu style)
Difference that this patch supports both zlib and zlib-gnu styles.
-compress-debug-sections option now supports next values:
-compress-debug-sections=zlib-gnu
-compress-debug-sections=zlib
-compress-debug-sections=none
Previously specifying -compress-debug-sections enabled zlib-gnu compression,
so anyone can put "-compress-debug-sections=zlib-gnu" to restore the behavior
that was before this patch for case when compression was enabled.
Differential revision: http://reviews.llvm.org/D20676
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270987 91177308-0d34-0410-b5e6-96231b3b80d8
It broke buildbot:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/13585/steps/build/logs/stdio
Initial commit message:
[llvm-mc] - Teach llvm-mc to generate zlib styled compression sections.
This patch is strongly based on previously reverted D20331.
(because of gnuutils < 2.26 does not support compressed debug sections in non zlib-gnu style)
Difference that this patch supports both zlib and zlib-gnu styles.
-compress-debug-sections option now supports next values:
-compress-debug-sections=zlib-gnu
-compress-debug-sections=zlib
-compress-debug-sections=none
Previously specifying -compress-debug-sections enabled zlib-gnu compression,
so anyone can put "-compress-debug-sections=zlib-gnu" to restore the behavior
that was before this patch for case when compression was enabled.
Differential revision: http://reviews.llvm.org/D20676
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270978 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is strongly based on previously reverted D20331.
(because of gnuutils < 2.26 does not support compressed debug sections in non zlib-gnu style)
Difference that this patch supports both zlib and zlib-gnu styles.
-compress-debug-sections option now supports next values:
-compress-debug-sections=zlib-gnu
-compress-debug-sections=zlib
-compress-debug-sections=none
Previously specifying -compress-debug-sections enabled zlib-gnu compression,
so anyone can put "-compress-debug-sections=zlib-gnu" to restore the behavior
that was before this patch for case when compression was enabled.
Differential revision: http://reviews.llvm.org/D20676
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270977 91177308-0d34-0410-b5e6-96231b3b80d8
PDBs can be extremely large. We're already mapping the entire
PDB into the process's address space, but to make matters worse
the blocks of the PDB are not arranged contiguously. So, when
we have something like an array or a string embedded into the
stream, we have to make a copy. Since it's convenient to use
traditional data structures to iterate and manipulate these
records, we need the memory to be contiguous.
As a result of this, we were using roughly twice as much memory
as the file size of the PDB, because every stream was copied
out and re-stitched together contiguously.
This patch addresses this by improving the MappedBlockStream
to allocate from a BumpPtrAllocator only when a read requires
a discontiguous read. Furthermore, it introduces some data
structures backed by a stream which can iterate over both
fixed and variable length records of a PDB. Since everything
is backed by a stream and not a buffer, we can read almost
everything from the PDB with zero copies.
Differential Revision: http://reviews.llvm.org/D20654
Reviewed By: ruiu
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270951 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for YAML round tripping dyld info lazy bindings. The storage and format of these is the same as regular bind opcodes, they are just interpreted differently by dyld, and can have DONE opcodes in the middle of the opcode lists.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270920 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for YAML round tripping dyld info weak bindings. The storage and format of these is the same as regular bind opcodes, they are just interpreted differently by dyld.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270911 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for YAML round tripping dyld info bind opcodes. Bind opcodes can have signed or unsigned LEB128 data, and they can have symbols associated with them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270901 91177308-0d34-0410-b5e6-96231b3b80d8
At some point we're going to need libObject to have this dependency, but as it is now this is causing too many headaches. This commit will reduce the linkage to just llvm-objdump where it is strictly needed, and we'll cross the libObject bridge later when we need it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270866 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Several changes were required for ThinLTO links involving bitcode
archive static libraries. With this patch clang/llvm bootstraps with
ThinLTO and gold.
The first is that the gold callbacks get_input_file and
release_input_file can normally be used to get file information for
each constituent bitcode file within an archive. However, these
interfaces lock the underlying file and can't be for each archive
constituent for ThinLTO backends where we get all the input files up
front and don't release any until after the backend threads complete.
However, it is sufficient to only get and release once per file, and
then each consituent bitcode file can be accessed via get_view. This
required saving some information to identify which file handle is the
"leader" for each claimed file sharing the same file descriptor, and
other information so that get_input_file isn't necessary later when
processing the backends.
Second, the module paths in the index need to distinguish between
different constituent bitcode files within the same archive file,
otherwise they will all end up with the same archive file path.
Do this by appending the offset within the archive for the start of the
bitcode file, returned by get_input_file when we claim each bitcode file,
and saving that along with the file handle.
Third, rather than have the function importer try to load a file based
on the module path identifier (which now contains a suffix to
distinguish different bitcode files within an archive), use a custom
module loader. This is the same approach taken in libLTO, and I am using
the support refactored into the new LTO.h header in r270509. The module
loader parses the bitcode files out of the memory buffers returned from
gold via the get_view callback and saved in a map. This also means that
we call the function importer directly, rather than add it to the pass
pipeline (which was in the plan to do already for other reasons).
Reviewers: pcc, joker.eph
Subscribers: llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D20559
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270814 91177308-0d34-0410-b5e6-96231b3b80d8
This is a support COFF feature. Ensure that we can display the weak externals
auxiliary symbol. It contains useful information (such as the default binding
and how to resolve the symbol).
This reapplies the previous patch with a modification which hopefully should fix
the endianness issues. The variadic call would promote the ulittle32_t to a
uint32_t which would lose the byte-swapping behaviour desired.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270813 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith identified this in post commit review of r270466. The
string sections in particular (in the future, possibly all sections - so
I'm not going to bother pulling out just the string sections for the
extra lifetime handling right now) need to remain valid during
processing of all inputs so that elements of the DWPStringPool can be
looked up repeatedly without having to make in-memory copies of string
contents in the noncompressed case (more common in dwp+dwp merge steps
where the memory is a bigger problem because the files are larger).
Using the SmallVector (or any vector) a reallocation on push_back could
cause any of the nested SmallStrings in small mode to move in memory and
invalid pointers to their contents. Using a deque the SmallStrings will
never move around since no elements are removed from the container.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270797 91177308-0d34-0410-b5e6-96231b3b80d8
We have need to reuse this functionality, including making
additional generic stream types that are smarter about how and
when they copy memory versus referencing the original memory.
So all of these structures belong in the common library
rather than being pdb specific.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270751 91177308-0d34-0410-b5e6-96231b3b80d8
This should actually address PR27855. This results in adding references to the system libs inside generated dylibs so that they get correctly pulled in when linking against the dylib.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270723 91177308-0d34-0410-b5e6-96231b3b80d8
searching for external symbols, and fall back to the SymbolResolver::findSymbol
method if the former returns null.
This makes RuntimeDyld behave more like a static linker: Symbol definitions
from within the current module's "logical dylib" will be preferred to
external definitions. We can build on this behavior in the future to properly
support weak symbol handling.
Custom symbol resolvers that override the findSymbolInLogicalDylib method may
notice changes due to this patch. Clients who have not overridden this method
should generally be unaffected, however users of the OrcMCJITReplacement class
may notice changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270716 91177308-0d34-0410-b5e6-96231b3b80d8
Try to figure out what each stream is, and dump its name.
This gives us a better picture of what streams we still don't
understand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270653 91177308-0d34-0410-b5e6-96231b3b80d8
This is a support COFF feature. Ensure that we can display the weak externals
auxiliary symbol. It contains useful information (such as the default binding
and how to resolve the symbol).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270648 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for parsing and dumping the following
symbol types:
S_LPROCREF
S_ENVBLOCK
S_COMPILE2
S_REGISTER
S_COFFGROUP
S_SECTION
S_THUNK32
S_TRAMPOLINE
As of this patch, the test PDB files no longer have any unknown
symbol types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270628 91177308-0d34-0410-b5e6-96231b3b80d8
