| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
This eliminates one overload on the term Raw.
Differential Revision: https://reviews.llvm.org/D29098
llvm-svn: 293104
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is not a list of pairs, it is a hash table data structure. We now
correctly parse this out and dump it from llvm-pdbdump.
We still need to understand the conditions that lead to a type
getting an entry in the hash adjuster table. That will be done
in a followup investigation / patch.
Differential Revision: https://reviews.llvm.org/D29090
llvm-svn: 293090
|
|
|
|
|
|
|
|
| |
Use warnings; other minor fixes (NFC).
Per Zachary Turner and Mehdi Amini suggestion to make only post-commit reviews.
llvm-svn: 287838
|
|
|
|
|
|
|
|
|
|
| |
This completes being able to write all the interesting
values of a PDB TPI stream.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D24370
llvm-svn: 281555
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This simplifies a lot of code, and will actually be necessary for
an upcoming patch to serialize TPI record hash values.
The idea before was that visitors should be examining records, not
modifying them. But this is no longer true with a visitor that
constructs a CVRecord from Yaml. To handle this until now, we
were doing some fixups on CVRecord objects at a higher level, but
the code is really awkward, and it makes sense to just have the
visitor write the bytes into the CVRecord. In doing so I uncovered
a few bugs related to `Data` and `RawData` and fixed those.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D24362
llvm-svn: 281067
|
|
|
|
|
|
|
|
|
|
| |
This writes the full sequence of type records described in
Yaml to the TPI stream of the PDB file.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D24316
llvm-svn: 281063
|
|
|
|
| |
llvm-svn: 280388
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we were assuming that any visitation of types would
necessarily be against a type we had binary data for. Reasonable
assumption when were just reading PDBs and dumping them, but once
we start writing PDBs from Yaml this breaks down, because we have
no binary data yet, only Yaml, and from that we need to read the
record kind and perform the switch based on that.
So this patch does that. Instead of having the visitor switch
on the kind that is already in the CVType record, we change the
visitTypeBegin() method to return the Kind, and switch on the
returned value. This way, the default implementation can still
return the value from the CVType, but the implementation which
visits Yaml records and serializes binary PDB type records can
use the field in the Yaml as the source of the switch.
llvm-svn: 280307
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were kind of hacking this together before by embedding the
ability to forward requests into the TypeDeserializer. When
we want to start adding more different kinds of visitor callback
interfaces though, this doesn't scale well and is very inflexible.
So introduce the notion of a pipeline, which itself implements
the TypeVisitorCallbacks interface, but which contains an internal
list of other callbacks to invoke in sequence.
Also update the existing uses of CVTypeVisitor to use this new
pipeline class for deserializing records before visiting them
with another visitor.
llvm-svn: 280293
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, our use case for the visitor has been to take a stream of bytes
representing a type stream, deserialize the records in sequence, and do
something with them, where "something" is determined by how the user
implements a particular set of callbacks on an abstract class.
For actually writing PDBs, however, we want to do the reverse. We have
some kind of description of the list of records in their in-memory format,
and we want to process each one. Perhaps by serializing them to a byte
stream, or perhaps by converting them from one description format (Yaml)
to another (in-memory representation).
This was difficult in the current model because deserialization and
invoking the callbacks were tightly coupled.
With this patch we change this so that TypeDeserializer is itself an
implementation of the particular set of callbacks. This decouples
deserialization from the iteration over a list of records and invocation
of the callbacks. TypeDeserializer is initialized with another
implementation of the callback interface, so that upon deserialization it
can pass the deserialized record through to the next set of callbacks. In
a sense this is like an implementation of the Decorator design pattern,
where the Deserializer is a decorator.
This will be useful for writing Pdbs from yaml, where we have a
description of the type records in Yaml format. In this case, the visitor
implementation would have each visitation callback method implemented in
such a way as to extract the proper set of fields from the Yaml, and it
could maintain state that builds up a list of these records. Finally at
the end we can pass this information through to another set of callbacks
which serializes them into a byte stream.
Reviewed By: majnemer, ruiu, rnk
Differential Revision: https://reviews.llvm.org/D23177
llvm-svn: 277871
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously this change was submitted from a Windows machine, so
changes made to the case of filenames and directory names did
not survive the commit, and as a result the CMake source file
names and the on-disk file names did not match on case-sensitive
file systems.
I'm resubmitting this patch from a Linux system, which hopefully
allows the case changes to make it through unfettered.
llvm-svn: 277213
|
|
|
|
|
|
| |
This reverts commit 4d1557ffac41e079bcb1abbcf04f512474dcd6fe.
llvm-svn: 277194
|
|
|
|
|
|
|
|
| |
In a previous patch, it was suggested to use all caps instead of
rolling caps for initialisms, so this patch changes everything
to do this.
llvm-svn: 277190
|
|
|
|
|
|
|
| |
Reviewed By: amccarth, ruiu
Differential Revision: https://reviews.llvm.org/D22693
llvm-svn: 277019
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was a pure virtual base class whose purpose was to abstract
away the notion of how you retrieve the layout of a discontiguous
stream of blocks in an Msf file. This led to too many layers of
abstraction making it difficult to figure out what was going on
and extend things. Ultimately, a stream's layout is decided by
its length and the array of block numbers that it lives on. So
rather than have an abstract base class which can return this in
any number of ways, it's more straightforward to simply store them
as fields of a trivial struct, and also to give a more appropriate
name.
This patch does that. It renames IMsfStreamData to MsfStreamLayout,
and deletes the 2 concrete implementations, DirectoryStreamData
and IndexedStreamData. MsfStreamLayout is a trivial struct
with the necessary data.
llvm-svn: 277018
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This provides a better layering of responsibilities among different
aspects of PDB writing code. Some of the MSF related code was
contained in CodeView, and some was in PDB prior to this. Further,
we were often saying PDB when we meant MSF, and the two are
actually independent of each other since in theory you can have
other types of data besides PDB data in an MSF. So, this patch
separates the MSF specific code into its own library, with no
dependencies on anything else, and DebugInfoCodeView and
DebugInfoPDB take dependencies on DebugInfoMsf.
llvm-svn: 276458
|
|
|
|
|
|
|
| |
We didn't read unique names correctly. As a result, we computed
hashes on (non-)unique names instead of unique names.
llvm-svn: 275150
|
|
|
|
|
|
| |
This gets writing of the PDB stream working.
llvm-svn: 274647
|
|
|
|
| |
llvm-svn: 274639
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This issue was encountered on libcmt.pdb, which has a type record that
looks like this:
Struct (0x1094) {
TypeLeafKind: LF_STRUCTURE (0x1505)
MemberCount: 3
Properties [ (0x200)
HasUniqueName (0x200)
]
FieldList: <field list> (0x1093)
DerivedFrom: 0x0
VShape: 0x0
SizeOf: 4
Name: <unnamed-tag>
LinkageName: .?AU<unnamed-tag>@@
}
The checks for startswith/endswith "<unnamed-tag>" should look at the
display name, not the linkage name.
llvm-svn: 274376
|
|
|
|
| |
llvm-svn: 274308
|
|
|
|
|
|
|
| |
This patch adds a function that corresponds to `fUDTAnon`
and use that to compute TPI hash values as the reference does.
llvm-svn: 273139
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21393
llvm-svn: 272930
|
|
|
|
|
|
|
| |
There was a regression introduced during type stream merging when
visiting a field list record. This has been fixed in this patch.
llvm-svn: 272929
|
|
|
|
|
|
|
|
| |
This reverts commit fb0dd311e1ad945827b8ffd5354f4810e2be1579.
This breaks some llvm-readobj tests.
llvm-svn: 272927
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows better catching of compiler errors since we can use
the override keyword to verify that methods are actually
overridden.
Also in this patch I've changed from storing a boolean Error
code everywhere to returning an llvm::Error, to propagate richer
error information up the call stack.
Reviewed By: ruiu, rnk
Differential Revision: http://reviews.llvm.org/D21410
llvm-svn: 272926
|
|
|
|
|
|
|
|
|
| |
Both parameters to visitTypeBegin are actually members of CVRecord,
so we can just pass CVRecord instead of destructuring it.
Differential Revision: http://reviews.llvm.org/D21435
llvm-svn: 272899
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21433
llvm-svn: 272898
|
|
|
|
| |
llvm-svn: 272894
|
|
|
|
| |
llvm-svn: 272889
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21418
llvm-svn: 272888
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21361
llvm-svn: 272815
|
|
|
|
| |
llvm-svn: 272728
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TPI hash table contains a parallel array for the type records.
For each type record R, a hash value is calculated by `H(R) % NumBuckets`
where H is a hash function, and the result is stored to a bucket element.
H is TPI1::hashPrec function in microsoft-pdb repository.
Our hash function does not support all type record types yet.
Currently it supports only records for line number.
I'll extend it in a follow up patch.
The aim of verify the hash table is not only detect corrupted files.
It ensures that our understanding of how the hash values are calculated
is correct.
llvm-svn: 272229
|
|
|
|
|
|
|
| |
Reviewed By: ruiu
Differential Revision: http://reviews.llvm.org/D21128
llvm-svn: 272172
|
|
|
|
| |
llvm-svn: 272078
|
|
|
|
|
|
| |
In the reference code, the field name is `cHashBuckets`.
llvm-svn: 272075
|
|
|
|
| |
llvm-svn: 272073
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 271954
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20945
llvm-svn: 271736
|
|
|
|
| |
llvm-svn: 271597
|
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20837
Reviewed By: ruiu
llvm-svn: 271346
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 271101
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 270951
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 270751
|
|
|
|
| |
llvm-svn: 270661
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 270653
|
|
|
|
| |
llvm-svn: 269381
|
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D19940
Reviewed By: rnk
llvm-svn: 268791
|