There doesn't seem to be a compelling reason why this method should be const
other than it was possible with the DIA implementation. The native session
is going to act as a symbol factory and cache. This could be acheived with
mutable (and the existing const_cast), but it seems cleaner to accept that
this method affects the state of the session.
This change eliminates an existing const_cast.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@306041 91177308-0d34-0410-b5e6-96231b3b80d8
Instead use target_link_libraries directly. Thanks to
Juergen Ributzka for the suggestion, which fixes an issue
when llvm is configured with no targets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305421 91177308-0d34-0410-b5e6-96231b3b80d8
Many times unit tests for different libraries would like to use
the same helper functions for checking common types of errors.
This patch adds a common library with helpers for testing things
in Support, and introduces helpers in here for integrating the
llvm::Error and llvm::Expected<T> classes with gtest and gmock.
Normally, we would just be able to write:
EXPECT_THAT(someFunction(), succeeded());
but due to some quirks in llvm::Error's move semantics, gmock
doesn't make this easy, so two macros EXPECT_THAT_ERROR() and
EXPECT_THAT_EXPECTED() are introduced to gloss over the difficulties.
Consider this an exception, and possibly only temporary as we
look for ways to improve this.
Differential Revision: https://reviews.llvm.org/D33059
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@305395 91177308-0d34-0410-b5e6-96231b3b80d8
Previously MappedBlockStream owned its own BumpPtrAllocator that
it would allocate from when a read crossed a block boundary. This
way it could still return the user a contiguous buffer of the
requested size. However, It's not uncommon to open a stream, read
some stuff, close it, and then save the information for later.
After all, since the entire file is mapped into memory, the data
should always be available as long as the file is open.
Of course, the exception to this is when the data isn't *in* the
file, but rather in some buffer that we temporarily allocated to
present this contiguous view. And this buffer would get destroyed
as soon as the strema was closed.
The fix here is to force the user to specify the allocator, this
way it can provide an allocator that has whatever lifetime it
chooses.
Differential Revision: https://reviews.llvm.org/D33858
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304623 91177308-0d34-0410-b5e6-96231b3b80d8
It was using the number of blocks of the entire PDB file as the number
of blocks of each stream that was created. This was only an issue in
the readLongestContiguousChunk function, which was never called prior.
This bug surfaced when I updated an algorithm to use this function and
the algorithm broke.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@303916 91177308-0d34-0410-b5e6-96231b3b80d8
There is often a lot of boilerplate code required to visit a type
record or type stream. The #1 use case is that you have a sequence
of bytes that represent one or more records, and you want to
deserialize each one, switch on it, and call a callback with the
deserialized record that the user can examine. Currently this
requires at least 6 lines of code:
codeview::TypeVisitorCallbackPipeline Pipeline;
Pipeline.addCallbackToPipeline(Deserializer);
Pipeline.addCallbackToPipeline(MyCallbacks);
codeview::CVTypeVisitor Visitor(Pipeline);
consumeError(Visitor.visitTypeRecord(Record));
With this patch, it becomes one line of code:
consumeError(codeview::visitTypeRecord(Record, MyCallbacks));
This is done by having the deserialization happen internally inside
of the visitTypeRecord function. Since this is occasionally not
desirable, the function provides a 3rd parameter that can be used
to change this behavior.
Hopefully this can significantly reduce the barrier to entry
to using the visitation infrastructure.
Differential Revision: https://reviews.llvm.org/D33245
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@303271 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-readobj hand rolls some CodeView parsing code for string
tables, so this patch updates it to re-use some of the newly
introduced parsing code in LLVMDebugInfoCodeView.
Differential Revision: https://reviews.llvm.org/D32772
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302052 91177308-0d34-0410-b5e6-96231b3b80d8
This was reverted due to a "missing" file, but in reality
what happened was that I renamed a file, and then due to
a merge conflict both the old file and the new file got
added to the repository. This led to an unused cpp file
being in the repo and not referenced by any CMakeLists.txt
but #including a .h file that wasn't in the repo. In an
even more unfortunate coincidence, CMake didn't report the
unused cpp file because it was in a subdirectory of the
folder with the CMakeLists.txt, and not in the same directory
as any CMakeLists.txt.
The presence of the unused file was then breaking certain
tools that determine file lists by globbing rather than
by what's specified in CMakeLists.txt
In any case, the fix is to just remove the unused file from
the patch set.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302042 91177308-0d34-0410-b5e6-96231b3b80d8
The patch is failing to add StringTableStreamBuilder.h, but that isn't
even discovered because the corresponding StringTableStreamBuilder.cpp
isn't added to any CMakeLists.txt file and thus never built. I think
this patch is just incomplete.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@302002 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we had knowledge of how to serialize and deserialize
a string table inside of DebugInfo/PDB, but the string table
that it serializes contains a piece that is actually considered
CodeView and can appear outside of a PDB. We already have logic
in llvm-readobj and MCCodeView to read and write this format,
so it doesn't make sense to duplicate the logic in DebugInfoPDB
as well.
This patch makes codeview::StringTable (for writing) and
codeview::StringTableRef (for reading), updates DebugInfoPDB
to use these classes for its own writing, and updates llvm-readobj
to additionally use StringTableRef for reading.
It's a bit more difficult to get MCCodeView to use this for
writing, but it's a logical next step.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301986 91177308-0d34-0410-b5e6-96231b3b80d8
With the forthcoming codeview::StringTable which a pdb::StringTable
would hold an instance of as one member, this ambiguity becomes
confusing. Rename to PDBStringTable to avoid this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@301948 91177308-0d34-0410-b5e6-96231b3b80d8
Previously the dumping of class definitions was very primitive,
and it made it hard to do more than the most trivial of output
formats when dumping. As such, we would only dump one line for
each field, and then dump non-layout items like nested types
and enums.
With this patch, we do a complete analysis of the object
hierarchy including aggregate types, bases, virtual bases,
vftable analysis, etc. The only immediately visible effects
of this are that a) we can now dump a line for the vfptr where
before we would treat that as padding, and b) we now don't
treat virtual bases that come at the end of a class as padding
since we have a more detailed analysis of the class's storage
usage.
In subsequent patches, we should be able to use this analysis
to display a complete graphical view of a class's layout including
recursing arbitrarily deep into an object's base class / aggregate
member hierarchy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@300133 91177308-0d34-0410-b5e6-96231b3b80d8
This was failing because I was using memcmp to compare two
objects that included padding bytes, which were uninitialized.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296681 91177308-0d34-0410-b5e6-96231b3b80d8
This was due to the test stream choosing an arbitrary partition
index for introducing the discontinuity rather than choosing
an index that would be correctly aligned for the type of data.
Also added an assertion into FixedStreamArray so that this will
be caught on all bots in the future, and not just the UBSan bot.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296661 91177308-0d34-0410-b5e6-96231b3b80d8
This re-adds all the binary stream tests. This was reverted due
to some misaligned reads. For now the offending test is
disabled while I investigate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296643 91177308-0d34-0410-b5e6-96231b3b80d8
I already created a BinaryStreamError class for this purpose,
so update the code to use that on the remaining occurrences
of errc values.
This should also address the issue which led to r296583.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296640 91177308-0d34-0410-b5e6-96231b3b80d8
Unfortunately, mingw's libstdc++ doesn't provide winsock2 errors.
That said, we should avoid raising OS-oriented error code in our code.
For now, I suggest to define custom error from std::error_category.
See also; https://reviews.llvm.org/D20592
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296583 91177308-0d34-0410-b5e6-96231b3b80d8
Unfortunately, mingw's libstdc++ doesn't provide winsock2 errors.
That said, we should avoid raising OS-oriented error code in our code.
For now, I suggest to define custom error from std::error_category.
See also; https://reviews.llvm.org/D20592
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296581 91177308-0d34-0410-b5e6-96231b3b80d8
A bug was uncovered where if you have a StreamRef whose ViewOffset
is > 0, then when you call readLongestContiguousChunk it will
succeed even when it shouldn't, and it always return you a
buffer that was taken as if the ViewOffset was 0.
Fixed this bug and added a test for it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296556 91177308-0d34-0410-b5e6-96231b3b80d8
Before the endianness was specified on each call to read
or write of the StreamReader / StreamWriter, but in practice
it's extremely rare for streams to have data encoded in
multiple different endiannesses, so we should optimize for the
99% use case.
This makes the code cleaner and more general, but otherwise
has NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296415 91177308-0d34-0410-b5e6-96231b3b80d8
This was reverted because it was breaking some builds, and
because of incorrect error code usage. Since the CL was
large and contained many different things, I'm resubmitting
it in pieces.
This portion is NFC, and consists of:
1) Renaming classes to follow a consistent naming convention.
2) Fixing the const-ness of the interface methods.
3) Adding detailed doxygen comments.
4) Fixing a few instances of passing `const BinaryStream& X`. These
are now passed as `BinaryStreamRef X`.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296394 91177308-0d34-0410-b5e6-96231b3b80d8
r296215, "[PDB] General improvements to Stream library."
r296217, "Disable BinaryStreamTest.StreamReaderObject temporarily."
r296220, "Re-enable BinaryStreamTest.StreamReaderObject."
r296244, "[PDB] Disable some tests that are breaking bots."
r296249, "Add static_cast to silence -Wc++11-narrowing."
std::errc::no_buffer_space should be used for OS-oriented errors for socket transmission.
(Seek discussions around llvm/xray.)
I could substitute s/no_buffer_space/others/g, but I revert whole them ATM.
Could we define and use LLVM errors there?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296258 91177308-0d34-0410-b5e6-96231b3b80d8
This has to do with big endian, but I can't fix it until
Monday. The code itself is fine, just the tests are wrong.
Disabling 3 tests for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296244 91177308-0d34-0410-b5e6-96231b3b80d8
This adds various new functionality and cleanup surrounding the
use of the Stream library. Major changes include:
* Renaming of all classes for more consistency / meaningfulness
* Addition of some new methods for reading multiple values at once.
* Full suite of unit tests for reader / writer functionality.
* Full set of doxygen comments for all classes.
* Streams now store their own endianness.
* Fixed some bugs in a few of the classes that were discovered
by the unit tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296215 91177308-0d34-0410-b5e6-96231b3b80d8
This is part of a larger effort to get the Stream code moved
up to Support. I don't want to do it in one large patch, in
part because the changes are so big that it will treat everything
as file deletions and add, losing history in the process.
Aside from that though, it's just a good idea in general to
make small changes.
So this change only changes the names of the Stream related
source files, and applies necessary source fix ups.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@296211 91177308-0d34-0410-b5e6-96231b3b80d8
In an effort to generalize this so it can be used by more than
just PDB code, we shouldn't assume little endian.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@295525 91177308-0d34-0410-b5e6-96231b3b80d8
Some PDBs or object files can contain references to other PDBs
where the real type information lives. When this happens,
all type indices in the original PDB are meaningless because
their records are not there.
With this patch we add the ability to pull type info from those
secondary PDBs.
Differential Revision: https://reviews.llvm.org/D29973
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@295382 91177308-0d34-0410-b5e6-96231b3b80d8
This was being parsed / serialized ad-hoc inside the code
for a specific PDB stream. But this data structure is used
in multiple ways / places within the PDB format. To be able
to re-use it we need to raise this code out and make it more
generic. In doing so, a number of bugs are fixed in the
original implementation, and support is added for growing
the hash table and deleting items from the hash table,
which had either been omitted or incorrect implemented in
the initial version.
Differential Revision: https://reviews.llvm.org/D28715
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292535 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a new class NameHashTableBuilder which creates /names streams.
This patch contains a test to confirm that a stream created by
NameHashTableBuilder can be read by NameHashTable reader class.
Differential Revision: https://reviews.llvm.org/D28707
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292040 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277213 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277190 91177308-0d34-0410-b5e6-96231b3b80d8