Some abstractions in LLVM "know" that they are reading in-bounds,
FixedStreamArray, and provide a simple result. This breaks down if the
stream map is bogus.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275010 91177308-0d34-0410-b5e6-96231b3b80d8
PDBFile::getBlockData didn't really return any indication that it
failed. It merely returned an empty buffer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275009 91177308-0d34-0410-b5e6-96231b3b80d8
We emitted debug info for globals/functions as if they all had external
linkage. Instead, emit local symbol records when appropriate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274676 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274376 91177308-0d34-0410-b5e6-96231b3b80d8
Somehow all the functionality to write PDB files got removed,
probably accidentally when uploading the patch perhaps the wrong
one got uploaded. This re-adds all the code, as well as the
corresponding test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274248 91177308-0d34-0410-b5e6-96231b3b80d8
a good error message to be produced.
This is nearly the last libObject interface that used ErrorOr and the last one
that appears in llvm/include/llvm/Object/MachO.h . For Mach-O objects this is
just a clean up because it’s version of getSymbolAddress() can’t return an
error.
I will leave it to the experts on COFF and ELF to actually add meaning full
error messages in their tests if they wish. And also leave it to these experts
to change the last two ErrorOr interfaces in llvm/include/llvm/Object/ObjectFile.h
for createCOFFObjectFile() and createELFObjectFile() if they wish.
Since there are no test cases for COFF and ELF error cases with respect to
getSymbolAddress() in the test suite this is no functional change (NFC).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273701 91177308-0d34-0410-b5e6-96231b3b80d8
We bailed out while printing codeview for an MSVC compiled
SemaExprCXX.cpp that used this record. The MS reference headers look
incorrect here, which is probably why we had this bug. They use a 32-bit
enum as the field type, but the actual record appears to use one byte
for the cookie kind followed by a flags byte.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273691 91177308-0d34-0410-b5e6-96231b3b80d8
Tweak the big-types.ll test case to catch this bug. We just need an
enumerator name that doesn't have a length that is a multiple of 4.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273477 91177308-0d34-0410-b5e6-96231b3b80d8
The basic structure is that once a list record goes over 64K, the last
subrecord of the list is an LF_INDEX record that refers to the next
record. Because the type record graph must be toplogically sorted, this
means we have to emit them in reverse order. We build the type record in
order of declaration, so this means that if we don't want extra copies,
we need to detect when we were about to split a record, and leave space
for a continuation subrecord that will point to the eventual split
top-level record.
Also adds dumping support for these records.
Next we should make sure that large method overload lists work properly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273294 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a function that corresponds to `fUDTAnon`
and use that to compute TPI hash values as the reference does.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273139 91177308-0d34-0410-b5e6-96231b3b80d8
64-bit PDBs never have FPO data. They have xdata instead.
Also improve error recovery of stream summary dumping while I'm here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273046 91177308-0d34-0410-b5e6-96231b3b80d8
There was a regression introduced during type stream merging when
visiting a field list record. This has been fixed in this patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272929 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272926 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit 879139e1c6577b09df52de56a6bab856a19ed185.
This was committed accidentally when I blindly typed git svn
dcommit instead of the command to generate a patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272693 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes an alignment issue by forcing all cached allocations
to be 8 byte aligned, and also fixes an issue arising on big
endian systems by writing ulittle32_t's instead of uint32_t's
in the test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272437 91177308-0d34-0410-b5e6-96231b3b80d8
This is the next step towards being able to write PDBs.
MemoryBuffer is immutable, and StreamInterface is our replacement
which can be any combination of read-only, read-write, or write-only
depending on the particular implementation.
The one place where we were creating a PDBFile (in RawSession) is
updated to subclass ByteStream with a simple adapter that holds
a MemoryBuffer, and initializes the superclass with the buffer's
array, so that all the functionality of ByteStream works
transparently.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272370 91177308-0d34-0410-b5e6-96231b3b80d8
This adds method and tests for writing to a PDB stream. With
this, even a PDB stream which is discontiguous can be treated
as a sequential stream of bytes for the purposes of writing.
Reviewed By: ruiu
Differential Revision: http://reviews.llvm.org/D21157
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272369 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272229 91177308-0d34-0410-b5e6-96231b3b80d8
