If we have multiple coverage counts for the same segment, we need to
add them up rather than arbitrarily choosing one. This fixes that and
adds a test with template instantiations to exercise it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218432 91177308-0d34-0410-b5e6-96231b3b80d8
get the literal string “Hello world” printed as a comment on the instruction
that loads the pointer to it. For now this is just for x86_64. So for object
files with relocation entries it produces things like:
leaq L_.str(%rip), %rax ## literal pool for: "Hello world\n"
and similar for fully linked images like executables:
leaq 0x4f(%rip), %rax ## literal pool for: "Hello world\n"
Also to allow testing against darwin’s otool(1), I hooked up the existing
-no-show-raw-insn option to the Mach-O parser code, added the new Mach-O
only -full-leading-addr option to match otool(1)'s printing of addresses and
also added the new -print-imm-hex option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218423 91177308-0d34-0410-b5e6-96231b3b80d8
For biendian targets like ARM and AArch64, it is useful to have the
output of the llvm-dwarfdump and llvm-objdump report the endianness
used when the object files were generated.
Patch by Charlie Turner.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218408 91177308-0d34-0410-b5e6-96231b3b80d8
This change fixes the ARM and AArch64 relocation visitors in
RelocVisitor. They were unconditionally assuming the object data are
little-endian. Tests have been added to ensure that the
llvm-dwarfdump utility does not crash when processing big-endian
object files.
Patch by Charlie Turner.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218407 91177308-0d34-0410-b5e6-96231b3b80d8
For biendian targets like ARM and AArch64, it is useful to have the
output of the llvm-dwarfdump and llvm-objdump report the endianness
used when the object files were generated.
Patch by Charlie Turner.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218391 91177308-0d34-0410-b5e6-96231b3b80d8
This change fixes the ARM and AArch64 relocation visitors in
RelocVisitor. They were unconditionally assuming the object data are
little-endian. Tests have been added to ensure that the
llvm-dwarfdump utility does not crash when processing big-endian
object files.
Patch by Charlie Turner.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218389 91177308-0d34-0410-b5e6-96231b3b80d8
Since llvm-cov shows the source file in its output, be careful about
potentially matching the check lines themselves.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218138 91177308-0d34-0410-b5e6-96231b3b80d8
Uncovered lines in the middle of a covered region weren't being shown
when filtering to a particular function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218109 91177308-0d34-0410-b5e6-96231b3b80d8
This format is simply a regular object file with the bitcode stored in a
section named ".llvmbc", plus any number of other (non-allocated) sections.
One immediate use case for this is to accommodate compilation processes
which expect the object file to contain metadata in non-allocated sections,
such as the ".go_export" section used by some Go compilers [1], although I
imagine that in the future we could consider compiling parts of the module
(such as large non-inlinable functions) directly into the object file to
improve LTO efficiency.
[1] http://golang.org/doc/install/gccgo#Imports
Differential Revision: http://reviews.llvm.org/D4371
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218078 91177308-0d34-0410-b5e6-96231b3b80d8
First step done in this commit is to get flush out enough of the
SymbolizerGetOpInfo() routine to symbolic an X86_64 hello world .o and
its loading of the literal string and call to printf. Also the code to
symbolicate the X86_64_RELOC_SUBTRACTOR relocation and a test is also
added to show a slightly more complicated case.
Next will be to flush out enough of SymbolizerSymbolLookUp() to get the
literal string “Hello world” printed as a comment on the instruction that load
the pointer to it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217893 91177308-0d34-0410-b5e6-96231b3b80d8
Teach yaml2obj how to make a bigobj COFF file. Like the rest of LLVM,
we automatically decide whether or not to use regular COFF or bigobj
COFF on the fly depending on how many sections the resulting object
would have.
This ends the task of adding bigobj support to LLVM.
N.B. This was tested by forcing yaml2obj to be used in bigobj mode
regardless of the number of sections. While a dedicated test was
written, the smallest I could make it was 36 MB (!) of yaml and it still
took a significant amount of time to execute on a powerful machine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217858 91177308-0d34-0410-b5e6-96231b3b80d8
This finishes the ability of llvm-objdump to print out all information from
the LC_DYLD_INFO load command.
The -bind option prints out symbolic references that dyld must resolve
immediately.
The -lazy-bind option prints out symbolc reference that are lazily resolved on
first use.
The -weak-bind option prints out information about symbols which dyld must
try to coalesce across images.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217853 91177308-0d34-0410-b5e6-96231b3b80d8
This changes the debug output of the llvm-cov tool to consistently
write to stderr, and moves the highlighting output closer to where
it's relevant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217838 91177308-0d34-0410-b5e6-96231b3b80d8
In r217746, though it was supposed to be NFC, I broke llvm-cov's
handling of showing regions without showing counts. This should've
shown up in the existing tests, except they were checking debug output
that was displayed regardless of what was actually output. I've moved
the relevant debug output to a more appropriate place so that the
tests catch this kind of thing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217835 91177308-0d34-0410-b5e6-96231b3b80d8
Similar to my previous -exports-trie option, the -rebase option dumps info from
the LC_DYLD_INFO load command. The rebasing info is a list of the the locations
that dyld needs to adjust if a mach-o image is not loaded at its preferred
address. Since ASLR is now the default, images almost never load at their
preferred address, and thus need to be rebased by dyld.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217709 91177308-0d34-0410-b5e6-96231b3b80d8
The raw profiles that are generated in compiler-rt always add padding
so that each profile is aligned, so we can simply treat files that
don't have this property as malformed.
Caught by Alexey's new ubsan bot. Thanks!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217708 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a call to sys::fs::equivalent that should've been to
CodeCoverageTool::equivalentFiles, which lets us restore the test of
r217476 that was removed in r217478.
This reverts r217478, but the test works this time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217646 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for reading the "bigobj" variant of COFF produced by
cl's /bigobj and mingw's -mbig-obj.
The most significant difference that bigobj brings is more than 2**16
sections to COFF.
bigobj brings a few interesting differences with it:
- It doesn't have a Characteristics field in the file header.
- It doesn't have a SizeOfOptionalHeader field in the file header (it's
only used in executable files).
- Auxiliary symbol records have the same width as a symbol table entry.
Since symbol table entries are bigger, so are auxiliary symbol
records.
Write support will come soon.
Differential Revision: http://reviews.llvm.org/D5259
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217496 91177308-0d34-0410-b5e6-96231b3b80d8
It appears that the -filename-equivalence option for testing llvm-cov
doesn't work correctly with -show-expansions. I'm reverting this test
to get the bots green while I look into fixing that.
This partially reverts r217476
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217478 91177308-0d34-0410-b5e6-96231b3b80d8
This is the plugin version of pr20882.
This handles the case of every common symbol being in the IR. We will need some
support from gold to handle the case where some symbols are in ELF and some in
the IR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217458 91177308-0d34-0410-b5e6-96231b3b80d8
This adds the printing of more load commands, so that the normal load commands
in a typical X86 Mach-O executable can all be printed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217172 91177308-0d34-0410-b5e6-96231b3b80d8
MachOObjectFile in lib/Object currently has no support for parsing the rebase,
binding, and export information from the LC_DYLD_INFO load command in final
linked mach-o images. This patch adds support for parsing the exports trie data
structure. It also adds an option to llvm-objdump to dump that export info.
I did the exports parsing first because it is the hardest. The information is
encoded in a trie structure, but the standard ObjectFile way to inspect content
is through iterators. So I needed to make an iterator that would do a
non-recursive walk through the trie and maintain the concatenation of edges
needed for the current string prefix.
I plan to add similar support in MachOObjectFile and llvm-objdump to
parse/display the rebasing and binding info too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216808 91177308-0d34-0410-b5e6-96231b3b80d8
This adds the printing of the LC_SEGMENT load command and sections,
LC_SYMTAB and LC_DYSYMTAB load commands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216795 91177308-0d34-0410-b5e6-96231b3b80d8