to llvm-objdump. This section is created with -fembed-bitcode option.
This requires the use of libxar and the Cmake and lit support were crafted by
Chris Bieneman!
rdar://26202242
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270491 91177308-0d34-0410-b5e6-96231b3b80d8
This will pave the way to introduce a full fledged symbol visitor
similar to how we have a type visitor, thus allowing the same
dumping code to be used in llvm-readobj and llvm-pdbdump.
Differential Revision: http://reviews.llvm.org/D20384
Reviewed By: rnk
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270475 91177308-0d34-0410-b5e6-96231b3b80d8
Now that the string pool is referential rather than maintaining its own
copy of string data, compressed sections (well, technically only the
debug_str section*) need to be preserved for the lifetime of the pool to
match.
* I'm not currently optimizing for memory footprint with compressed
input - the major memory limit I'm hitting is on dwp+dwp merge steps
and we aren't currently compressing contents in dwp files, just in the
.dwo inputs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270462 91177308-0d34-0410-b5e6-96231b3b80d8
Main problem here was that SHF_COMPRESSED has the same value with
XCORE_SHF_CP_SECTION, which was included as standart (common) flag.
As far I understand xCore is a family of controllers and it that
means it's constant should be processed separately,
only if e_machine == EM_XCORE, otherwise llvm-readobj would output
different constants twice for compressed section:
Flags [
..
SHF_COMPRESSED (0x800)
..
XCORE_SHF_CP_SECTION (0x800)
..
]
what probably does not make sence if you're not working with xcore file.
Differential revision: http://reviews.llvm.org/D20273
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270320 91177308-0d34-0410-b5e6-96231b3b80d8
This fills section data with 0xDEADBEEF and segment data not inside a section with 0xBAADDA7A. This results in yaml2obj generating a matching size object file. Any additional bytes in the file are zero'd.
This is a starting point for populating the remaining segment data, and provides a hex viewable file that you can easily see the missing data in.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270286 91177308-0d34-0410-b5e6-96231b3b80d8
In addition to clarifying the warning message this contains a minor functional
change in that it now warns if the *immediate* parent directory in which the
missing PCM is expected to be isn't found.
This patch also includes a more comprehensive testcase.
rdar://problem/25860711
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270269 91177308-0d34-0410-b5e6-96231b3b80d8
DBI stream contains a stream number of the symbol record stream.
Symbol record streams is an array of length-type-value members.
Each member represents one symbol.
Publics stream contains offsets to the symbol record stream.
This patch is to print out all symbols that are referenced by
the publics stream.
Note that even with this patch, llvm-pdbdump cannot dump all the
information in a publics stream since it contains more information
than symbol names. I'll improve it in followup patches.
Differential Revision: http://reviews.llvm.org/D20480
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270262 91177308-0d34-0410-b5e6-96231b3b80d8
Now that MachO load command fields are fully covered we can fill unaccounted for bytes with 0. That allows us to sparsely specify YAML to simplify tests.
Simplifying load_commands test accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270158 91177308-0d34-0410-b5e6-96231b3b80d8
This splits ProfileSummary into two classes: a ProfileSummary class that has methods to convert from/to metadata and a ProfileSummaryBuilder class that computes the profiles summary which is in ProfileData.
Differential Revision: http://reviews.llvm.org/D20314
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270136 91177308-0d34-0410-b5e6-96231b3b80d8
This re-applies r270115.
Many of the MachO load commands can have data appended after the command structure. This data is frequently strings, but can actually be anything. This patch adds support for three optional fields on load command yaml descriptions.
The new PayloadString YAML field is populated with the data after load commands known to have strings as extra data.
The new ZeroPadBytes YAML field is a count of zero'd bytes after the end of the load command structure before the next command. This can apply anywhere in the file. MachO2YAML verifies that bytes are zero before populating this field, and YAML2MachO will add zero'd bytes.
The new PayloadBytes YAML field stores all bytes after the end of the load command structure before the next command if they are non-zero. This is a catch all for all unhandled bytes. If MachO2Yaml populates PayloadBytes it will not populate ZeroPadBytes, instead zero'd bytes will be in the PayloadBytes structure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270124 91177308-0d34-0410-b5e6-96231b3b80d8
Many of the MachO load commands can have data appended after the command structure. This data is frequently strings, but can actually be anything. This patch adds support for three optional fields on load command yaml descriptions.
The new PayloadString YAML field is populated with the data after load commands known to have strings as extra data.
The new ZeroPadBytes YAML field is a count of zero'd bytes after the end of the load command structure before the next command. This can apply anywhere in the file. MachO2YAML verifies that bytes are zero before populating this field, and YAML2MachO will add zero'd bytes.
The new PayloadBytes YAML field stores all bytes after the end of the load command structure before the next command if they are non-zero. This is a catch all for all unhandled bytes. If MachO2Yaml populates PayloadBytes it will not populate ZeroPadBytes, instead zero'd bytes will be in the PayloadBytes structure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270115 91177308-0d34-0410-b5e6-96231b3b80d8
InterleavedAccessPass is an IR-level pass, so this change will enable testing
it with opt. This is part of D20250.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270101 91177308-0d34-0410-b5e6-96231b3b80d8
Transition InstrProf and Coverage over to the stricter Error/Expected
interface.
Changes since the initial commit:
- Fix error message printing in llvm-profdata.
- Check errors in loadTestingFormat() + annotateAllFunctions().
- Defer error handling in InstrProfIterator to InstrProfReader.
- Remove the base ProfError class to work around an MSVC ICE.
Differential Revision: http://reviews.llvm.org/D19901
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270020 91177308-0d34-0410-b5e6-96231b3b80d8
This refactoring is to reduce code duplication between the 32-bit and 64-bit code paths. This refactoring will also make the special casing for other data after load commands cleaner.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@270001 91177308-0d34-0410-b5e6-96231b3b80d8
Having an enum member named Default is quite confusing: Is it distinct
from the others?
This patch removes that member and instead uses Optional<Reloc> in
places where we have a user input that still hasn't been maped to the
default value, which is now clear has no be one of the remaining 3
options.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269988 91177308-0d34-0410-b5e6-96231b3b80d8
MC only needs to know if the output is PIC or not. It never has to
decide about creating GOTs and PLTs for example. The only thing that
MC itself uses this information for is expanding "macros" in sparc and
mips. The rest I am pretty sure could be moved to CodeGen.
This is a cleanup and isolates the code from future changes to
Reloc::Model.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269909 91177308-0d34-0410-b5e6-96231b3b80d8
Coverage mapping data is organized in a sequence of blocks, each of which is expected
to be aligned by 8 bytes. This feature is used when reading those blocks, see
VersionedCovMapFuncRecordReader::readFunctionRecords(). If a misaligned covearge
mapping data has more than one block, it causes llvm-cov to fail.
Differential Revision: http://reviews.llvm.org/D20285
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269887 91177308-0d34-0410-b5e6-96231b3b80d8
* Reworks the CVSymbolTypes.def to work similarly to TypeRecords.def.
* Moves some enums from SymbolRecords.h to CodeView.h to maintain
consistency with how we do type records.
* Generalize a few simple things like the record prefix
* Define the leaf enum and the kind enum similar to how we do with tyep
records.
Differential Revision: http://reviews.llvm.org/D20342
Reviewed By: amccarth, rnk
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269867 91177308-0d34-0410-b5e6-96231b3b80d8
structs"
This reverts commits r269845, r269846, and r269850 as they
introduce a crash in obj2yaml when trying to do a roundtrip.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269865 91177308-0d34-0410-b5e6-96231b3b80d8
I don't yet fully understand the meaning of these data strcutures,
but at least it seems that their sizes and types are correct.
With this change, we can read publics streams till end.
Differential Revision: http://reviews.llvm.org/D20343
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269861 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for all the MachO *_command structures. The load_command payloads still are not represented, but that will come next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269808 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Colons can appear in Windows paths after drive letters. Both colon and
semicolon are valid characters in filenames, but neither are very
common. Semicolon seems just as good, and makes the test pass on
Windows.
Reviewers: tejohnson
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D20332
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269798 91177308-0d34-0410-b5e6-96231b3b80d8
when the object is in an archive to use something like libx.a(foo.o) as part of
the error message.
Also changed llvm-objdump and llvm-size to be like llvm-nm and ignore non-object
files in archives and not produce any error message.
To do this Archive::Child::getAsBinary() was changed from ErrorOr<...> to
Expected<...> then that was threaded up to its users.
Converting this interface 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 one place yet to be fully converted.
Again there some were bugs in the existing code that did not deal with the
old ErrorOr<> return values. So now with Expected<> since they must be
checked and the error handled, I added a TODO and a comments for those.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269784 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for all the MachO *_command structures. The load_command payloads still are not represented, but that will come next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269782 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Add support to control where files for a distributed backend (the
individual index files and optional imports files) are created.
This is invoked with a new thinlto-prefix-replace option in the gold
plugin and llvm-lto. If specified, expects a string of the form
"oldprefix:newprefix", and instead of generating these files in the
same directory path as the corresponding bitcode file, will use a path
formed by replacing the bitcode file's path prefix matching oldprefix
with newprefix.
Also add a new replace_path_prefix helper to Path.h in libSupport.
Depends on D19636.
Reviewers: joker.eph
Subscribers: llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D19644
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269771 91177308-0d34-0410-b5e6-96231b3b80d8
This diagnostic could be improved by adding the name of the input file
containing the invalid data and/or some information about how to
identify the specific offending attribute/tag in the input. But that's
not an immediate priority as these corner cases of invalid input
shouldn't come up too often.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269727 91177308-0d34-0410-b5e6-96231b3b80d8
The diagnostic could be improved a bit to include information about
which input file had the mistake (& which unit (counted, since the name
of the unit won't be accessible) within the input).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269723 91177308-0d34-0410-b5e6-96231b3b80d8
