This index lists the reports available in the 'coverage' sub-directory.
This will help navigate coverage output from large projects.
This commit factors the file creation code out of SourceCoverageView and
into CoveragePrinter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274029 91177308-0d34-0410-b5e6-96231b3b80d8
This makes it a bit more generic, in case we want to emit summary
reports in different formats in the future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@274026 91177308-0d34-0410-b5e6-96231b3b80d8
Passing -output-dir path/to/dir to llvm-cov show creates path/to/dir if
it doesn't already exist, and prints reports into that directory.
In function view mode, all views are written into
path/to/dir/functions.$EXTENSION. In file view mode, all views are
written into path/to/dir/coverage/$PATH.$EXTENSION.
Changes since the initial commit:
- Avoid accidentally closing stdout twice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273985 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r273971. test/profile/instrprof-visibility.cpp is
failing because of an uncaught error in SafelyCloseFileDescriptor.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273978 91177308-0d34-0410-b5e6-96231b3b80d8
Passing -output-dir path/to/dir to llvm-cov show creates path/to/dir if
it doesn't already exist, and prints reports into that directory.
In function view mode, all views are written into
path/to/dir/functions.$EXTENSION. In file view mode, all views are
written into path/to/dir/coverage/$PATH.$EXTENSION.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273971 91177308-0d34-0410-b5e6-96231b3b80d8
allow a good error message to be produced.
I added the one test case that the object file tools could produce an error
message. The other two errors can’t be triggered if the input file is passed
through sys::fs::identify_magic(). But the malformedError("bad magic number")
does get triggered by the logic in llvm-dsymutil when dealing with a normal
Mach-O file. The other "File too small ..." error would take a logic error
currently to produce and is not tested for.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273946 91177308-0d34-0410-b5e6-96231b3b80d8
binutils ar uses -plugin to specify the LTO plugin, but LLVM doesn't
need this as it doesn't use a plugin for LTO. Accepting (and ignoring)
the option allows interoperability with existing build systems and
make downstream consumers life much easier.
No objections from Rafael on this change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273938 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Our YAML library's handling of tags isn't perfect, but it is good enough to get rid of the need for the --format argument to yaml2obj. This patch does exactly that.
Instead of requiring --format, it infers the format based on the tags found in the object file. The supported tags are:
!ELF
!COFF
!mach-o
!fat-mach-o
I have a corresponding patch that is quite large that fixes up all the in-tree test cases.
Reviewers: rafael, Bigcheese, compnerd, silvas
Subscribers: compnerd, llvm-commits
Differential Revision: http://reviews.llvm.org/D21711
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273915 91177308-0d34-0410-b5e6-96231b3b80d8
The last import is the penultimate entry, the last entry is nulled out.
Data beyond the null entry should not be considered to hold import
entries.
This fixes PR28302.
N.B. I am working on a reduced testcase, the one in PR28302 is too
large.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273790 91177308-0d34-0410-b5e6-96231b3b80d8
If a sub-view has already been rendered, it's helpful to re-render the
expansion site before rendering the next expansion view. Make this fact
explicit in the rendering interface, instead of hiding it behind an
awkward Optional<LineRef> parameter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273789 91177308-0d34-0410-b5e6-96231b3b80d8
This makes it easier to add renderers for new kinds of output formats.
- Define and document a pure-virtual coverage rendering interface.
- Move the text-based rendering logic into its a new file.
- Re-work the API to better reflect the presentation/formatting split.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273767 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds round-trip support for MachO Universal binaries to obj2yaml and yaml2obj. Universal binaries have a header and list of architecture structures, followed by a the individual object files at specified offsets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273719 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
They were using output streams inconsistently. One also had a grammar
bug.
I noticed these while trying to pare down D18278.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273642 91177308-0d34-0410-b5e6-96231b3b80d8
A lot of this code is going to move into the text-based coverage
renderer, and won't be able to use Options directly. Use the getter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273635 91177308-0d34-0410-b5e6-96231b3b80d8
A SourceName can be a file or a function. It makes sense to attach this
information to a SourceCoverageView, seeing as views (1) already point
to the text corresponding to the relevant source code and (2) are
already used to render that text along with the SourceNames.
This is a nice cleanup which is independent of the upcoming html patch.
While we're at it, document the fields in SourceCoverageView.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273634 91177308-0d34-0410-b5e6-96231b3b80d8
Pull LineCoverageInfo out of SourceCoverageView and rename it so that it
doesn't conflict with another class of the same name in
CoverageSummaryInfo.h.
This cuts down on the amount of code we have to move into a `protected`
section of SourceCoverageView for the upcoming html patch. It also makes
the code a bit clearer: having two LineCoverageInfo's is strange.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273633 91177308-0d34-0410-b5e6-96231b3b80d8
32-bit Mach headers don't have reserved fields. When generating the
mapping for 32-bit headers leaving off the reserved field will result in
parse errors if the field is present in the yaml.
Added a CHECK-NOT line to ensure that mach_header.yaml isn't adding a
reserved field, and a test to ensure that the parser error gets hit with
32-bit headers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273623 91177308-0d34-0410-b5e6-96231b3b80d8
This flag was introduced in r269655 with the new diagnostic handler for llc. Its
purpose was to keep the old behavior for some of the tests that didn't recover
well after an error. Those tests have been fixed, so now it's safe to remove the
flag entirely.
Fixes PR27759.
Differential Revision: http://reviews.llvm.org/D21368
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273554 91177308-0d34-0410-b5e6-96231b3b80d8
Improve the previous change by using a local function to reduce the duplication
of the object file scanning. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273429 91177308-0d34-0410-b5e6-96231b3b80d8
This patch changes single method of llvm-readobj.
It teaches SHT_GNU_verdef dumper to print version dependencies,
also it removes few fields from output that can be dumped with other keys
and slightly refactors code.
Testcase was also modified to match the changes.
Change is required for testcases of upcoming lld patches.
Differential revision: http://reviews.llvm.org/D21552
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273417 91177308-0d34-0410-b5e6-96231b3b80d8
Try to be more clever about selecting the default format. When an existing
archive is used, use the type of the archive to determine the format. When
existing members are present, use the first member's format to determine the
format to use. If we are creating an empty archive (MRI mode) or are adding
non-object members, default to the current behaviour of using the host type due
to the lack of a better alternative. This aids in cross-compilation on Darwin
to non-Darwin platforms which rely on GNU format archives.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273373 91177308-0d34-0410-b5e6-96231b3b80d8
This change is motivated by an upcoming change to the metadata representation
used for CFI. The indirect function call checker needs type information for
external function declarations in order to correctly generate jump table
entries for such declarations. We currently associate such type information
with declarations using a global metadata node, but I plan [1] to move all
such metadata to global object attachments.
In bitcode, metadata attachments for function declarations appear in the
global metadata block. This seems reasonable to me because I expect metadata
attachments on declarations to be uncommon. In the long term I'd also expect
this to be the case for CFI, because we'd want to use some specialized bitcode
format for this metadata that could be read as part of the ThinLTO thin-link
phase, which would mean that it would not appear in the global metadata block.
To solve the lazy loaded metadata issue I was seeing with D20147, I use the
same bitcode representation for metadata attachments for global variables as I
do for function declarations. Since there's a use case for metadata attachments
in the global metadata block, we might as well use that representation for
global variables as well, at least until we have a mechanism for lazy loading
global variables.
In the assembly format, the metadata attachments appear after the "declare"
keyword in order to avoid a parsing ambiguity.
[1] http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html
Differential Revision: http://reviews.llvm.org/D21052
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273336 91177308-0d34-0410-b5e6-96231b3b80d8
with the -macho and -universal-headers flags.
Just a follow on to r273207, I missed updating the printing of the fat magic
number when the universal file is a 64-bit universal file.
rdar://26899493
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273324 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
llvm-mc is a developer tool, as such it make sense for it to use new
features by default.
This doesn't change the user facing clang, which still defaults to non
relaxable relocations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273014 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
Summary:
The Mips implementation only covers the feature bits described by the ELF
e_flags so far. Mips stores additional feature bits such as MSA in the
.MIPS.abiflags section.
Also fixed a small bug this revealed where microMIPS wouldn't add the
EF_MIPS_MICROMIPS flag when using -filetype=obj.
Reviewers: echristo, rafael
Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits
Differential Revision: http://reviews.llvm.org/D21125
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272880 91177308-0d34-0410-b5e6-96231b3b80d8