This is made possible by removing an assert in llc that assumed
MIRParser::parseLLVMModule would exit on error. MIRParser's documentation states
that it returns null if a parsing error occurs, so there's no reason to assert.
We can instead just fall through to where the check for a module is performed
and exit if it is null.
This commit is part of the clean-up after r269655.
Fixes PR27770
Differential Revision: http://reviews.llvm.org/D20371
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272254 91177308-0d34-0410-b5e6-96231b3b80d8
looking for it along $PATH. This allows installs of LLVM tools outside of
$PATH to find the symbolizer and produce pretty backtraces if they crash.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272232 91177308-0d34-0410-b5e6-96231b3b80d8
As suggested by clang-tidy's performance-unnecessary-copy-initialization.
This can easily hit lifetime issues, so I audited every change and ran the
tests under asan, which came back clean.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272126 91177308-0d34-0410-b5e6-96231b3b80d8
In order to efficiently write PDBs, we need to be able to make a
StreamWriter class similar to a StreamReader, which can transparently deal
with writing to discontiguous streams, and we need to use this for all
writing, similar to how we use StreamReader for all reading.
Most discontiguous streams are the typical numbered streams that appear in
a PDB file and are described by the directory, but the exception to this,
that until now has been parsed by hand, is the directory itself.
MappedBlockStream works by querying the directory to find out which blocks
a stream occupies and various other things, so naturally the same logic
could not possibly work to describe the blocks that the directory itself
resided on.
To solve this, I've introduced an abstraction IPDBStreamData, which allows
the client to query for the list of blocks occupied by the stream, as well
as the stream length. I provide two implementations of this: one which
queries the directory (for indexed streams), and one which queries the
super block (for the directory stream).
This has the side benefit of vastly simplifying the code to parse the
directory. Whereas before a mini state machine was rolled by hand, now we
simply use FixedStreamArray to read out the stream sizes, then build a
vector of FixedStreamArrays for the stream map, all in just a few lines of
code.
Reviewed By: ruiu
Differential Revision: http://reviews.llvm.org/D21046
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271982 91177308-0d34-0410-b5e6-96231b3b80d8
Changes since the initial commit:
- Normalize file paths read from the file to prevent Windows path
separators from escaping parts of the path.
- Since we need to store the normalized file paths in WeightedFile,
don't do tricky things to keep the source MemoryBuffer alive.
- Don't use list-initialization for a std::string in WeightedFile.
Differential Revision: http://reviews.llvm.org/D20980
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271953 91177308-0d34-0410-b5e6-96231b3b80d8
Changes since the initial commit:
- Normalize file paths read from the file to prevent Windows path
separators from escaping parts of the path.
- Since we need to store the normalized file paths in WeightedFile,
don't do tricky things to keep the source MemoryBuffer alive.
Differential Revision: http://reviews.llvm.org/D20980
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271949 91177308-0d34-0410-b5e6-96231b3b80d8
This is the simplest possible patch to get some kind of YAML
output. All it dumps is the MSF header fields so that in
theory an empty MSF file could be reconstructed.
Reviewed By: ruiu, majnemer
Differential Revision: http://reviews.llvm.org/D20971
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271939 91177308-0d34-0410-b5e6-96231b3b80d8
and/or tests aren't working on Windows currently.
There seems to be some problem with quoting the file paths. I don't
understand the test structure here or the code well enough to try to
come up with a way to correctly handle paths with back slashes in them,
and this has caused the Windows builds to be failing for 7 hours now, so
I'm reverting the whole thing to bring them back to life. Sorry for the
disruption, but a couple of these were bug fixes anyways that can be
folded into a fresh commit.
Reverts the following patches:
r271756: Clean up the way we create the input filenames buffer (NFC)
r271748: Fix use-after-free from discarded MemoryBuffer (NFC)
r271710: Fix option description (NFC)
r271709: Add option to ingest filepaths from a file
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271760 91177308-0d34-0410-b5e6-96231b3b80d8
Create the buffer before calling parseInputFilenamesFile(), and add a
comment explaining why this is done.
Thanks to David Li for the suggestion!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271756 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Previously we would try to load PDBs for every PE executable we tried to
symbolize. If that failed, we would fall back to DWARF. If there wasn't
any DWARF, we'd print mostly useless symbol information using the export
table.
With this change, we only try to load PDBs for executables that claim to
have them. If that fails, we can now print an error rather than falling
back silently. This should make it a lot easier to diagnose and fix
common symbolization issues, such as not having DIA or not having a PDB.
Reviewers: zturner, eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D20982
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271725 91177308-0d34-0410-b5e6-96231b3b80d8
This opens the door to introducing a YAML outputter which can be
used for machine consumption. Currently the yaml output style
is unimplemented and returns an error if you try to use it.
Reviewed By: rnk, ruiu
Differential Revision: http://reviews.llvm.org/D20967
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271712 91177308-0d34-0410-b5e6-96231b3b80d8
This re-applies r271611, and hopefully the bots won't break this time.
Although ld64 always outputs linkedit data in the same order, it isn't actually required to. This change makes yaml2obj resilient if the offsets are in arbitrary order.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271687 91177308-0d34-0410-b5e6-96231b3b80d8
When printing line information and file checksums, we were printing
the file offset field from the struct header. This teaches
llvm-pdbdump how to turn those numbers into the filename. In the
case of file checksums, this is done by looking in the global
string table. In the case of line contributions, this is done
by indexing into the file names buffer of the DBI stream. Why
they use a different technique I don't know.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271630 91177308-0d34-0410-b5e6-96231b3b80d8
To facilitate this, a couple of changes had to be made:
1. `ModuleSubstream` got moved from `DebugInfo/PDB` to
`DebugInfo/CodeView`, and various codeview related types are defined
there. It turns out `DebugInfo/CodeView/Line.h` already defines many of
these structures, but this is really old code that is not endian aware,
doesn't interact well with `StreamInterface` and not very helpful for
getting stuff out of a PDB. Eventually we should migrate the old readobj
`COFFDumper` code to these new structures, or at least merge their
functionality somehow.
2. A `ModuleSubstream` visitor is introduced. Depending on where your
module substream array comes from, different subsets of record types can
be expected. We are already hand parsing these substream arrays in many
places especially in `COFFDumper.cpp`. In the future we can migrate these
paths to the visitor as well, which should reduce a lot of code in
`COFFDumper.cpp`.
Differential Revision: http://reviews.llvm.org/D20936
Reviewed By: ruiu, majnemer
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271621 91177308-0d34-0410-b5e6-96231b3b80d8
Although ld64 always outputs linkedit data in the same order, it isn't actually required to. This change makes yaml2obj resilient if the offsets are in arbitrary order.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271611 91177308-0d34-0410-b5e6-96231b3b80d8
This commit adds round tripping for MachO symbol data. Symbols are entries in the name list, that contain offsets into the string table which is at the end of the __LINKEDIT segment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271604 91177308-0d34-0410-b5e6-96231b3b80d8
This first pass only splits apart the records and dumps the line
info kinds and binary data. Subsequent patches will parse out
the binary data into more useful information and dump it in
detail.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271576 91177308-0d34-0410-b5e6-96231b3b80d8
Unlike other sections that can grow to any size, the COFF section header
stream has maximum length because each record is fixed size and the COFF
file format limits the maximum number of sections. So I decided to not
create a specific stream class for it. Instead, I added a member function
to DbiStream class which returns a vector of COFF headers.
Differential Revision: http://reviews.llvm.org/D20717
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271557 91177308-0d34-0410-b5e6-96231b3b80d8
This directory is used to find if there is a PDB associated with an
executable. I plan to use this functionality to teach llvm-symbolizer
whether it should use DIA or DWARF to symbolize a given DLL.
Reviewers: majnemer
Differential Revision: http://reviews.llvm.org/D20885
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271539 91177308-0d34-0410-b5e6-96231b3b80d8
The new option makes it possible to build external projects as part of
the llvm build without copying (or symlinking) then into llvm/tool with
specifying a few additional cmake variables.
Example usage (2 additional project called foo and bar):
-DLLVM_EXTERNAL_PROJECTS="Foo;Bar"
-DLLVM_EXTERNAL_FOO_SOURCE_DIR=/src/foo
-DLLVM_EXTERNAL_BAR_SOURCE_DIR=/src/bar
Note: This is the extension of the approach we already support for
clang/lldb/poly with adding an option to specify additional supported
projects.
Differential revision: http://reviews.llvm.org/D20838
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@271440 91177308-0d34-0410-b5e6-96231b3b80d8
