llvm-svn: 272078

In the reference code, the field name is `cHashBuckets`.

llvm-svn: 272075

llvm-svn: 272073

Changes since the initial commit:
- Use echo instead of printf. This should side-step the character
  escaping issues on Windows.

Differential Revision: http://reviews.llvm.org/D20980

llvm-svn: 272068

SHT_GNU_verneed (.gnu.version_r) is a version dependency section.
It was the last symbol versioning relative section that was not dumped,
now it is.

Differential revision: http://reviews.llvm.org/D21024

llvm-svn: 271998

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

llvm-svn: 271982

This reverts commit r271953. It's still breaking on Windows, though the
list initialization issue is fixed:

http://bb.pgr.jp/builders/ninja-clang-i686-msc19-R/builds/3751

llvm-svn: 271963

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

llvm-svn: 271953

This reverts commit r271949. It breaks the Windows build:

http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/12796

llvm-svn: 271952

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

llvm-svn: 271949

llvm-svn: 271943

This is based on post-commit feedback from Sean Silva.

llvm-svn: 271942

llvm-svn: 271940

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

llvm-svn: 271939

The data strucutre in the new FPO stream is described in the
PE/COFF spec. There is one record per function if frame pointer
is omitted.

Differential Revision: http://reviews.llvm.org/D20999

llvm-svn: 271926

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
llvm-svn: 271760

Create the buffer before calling parseInputFilenamesFile(), and add a
comment explaining why this is done.

Thanks to David Li for the suggestion!

llvm-svn: 271756

Thanks to Justin Bogner for pointing this out!

Caught by ASAN.

llvm-svn: 271748

Differential Revision: http://reviews.llvm.org/D20945

llvm-svn: 271736

In my earlier patch r271690 I missed passing a map by reference in one
place.

llvm-svn: 271732

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

llvm-svn: 271725

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

llvm-svn: 271712

llvm-svn: 271710

Differential Revision: http://reviews.llvm.org/D20980

llvm-svn: 271709

No longer need to compute the imports in each backend thread.

llvm-svn: 271690

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.

llvm-svn: 271687

llvm-svn: 271681

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.

llvm-svn: 271630

llvm-svn: 271622

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

llvm-svn: 271621

llvm-svn: 271620

This reverts commit r271611 because it broke a bot:

http://bb.pgr.jp/builders/cmake-llvm-x86_64-linux/builds/38184

I don't currently have a handle on what went wrong, so I'll revert while I investigate.

llvm-svn: 271613

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.

llvm-svn: 271611

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.

llvm-svn: 271604

llvm-svn: 271585

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.

llvm-svn: 271576

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

llvm-svn: 271557

This matches the COFF spec

llvm-svn: 271549

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

llvm-svn: 271539

llvm-svn: 271537