MachO and COFF quite reasonably only define the size for common symbols.
We used to try to figure out the "size" by computing the gap from one symbol to
the next.
This would not be correct in general, since a part of a section can belong to no
visible symbol (padding, private globals).
It was also really expensive, since we would walk every symbol to find the size
of one.
If a caller really wants this, it can sort all the symbols once and get all the
gaps ("size") in O(n log n) instead of O(n^2).
On MachO this also has the advantage of centralizing all the checks for an
invalid n_sect.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238028 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-cov was truncating numbers that were larger than a particular
fixed width, which is as confusing as it is useless. Instead, we use
engineering notation with SI prefix for magnitude.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237307 91177308-0d34-0410-b5e6-96231b3b80d8
Since the coverage mapping reader and the instrprof reader were
emitting a shared set of error codes, the error messages you'd get
back from llvm-cov were ambiguous about what was actually wrong. Add
another error category to fix this.
I've also improved the wording on a couple of the instrprof errors,
for consistency.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236665 91177308-0d34-0410-b5e6-96231b3b80d8
Specifically, this patch correctly respects the -demangle option,
and additionally adds a hidden --relative-address option allows
input addresses to be relative to the module load address instead
of absolute addresses into the image.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236653 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds the --load-address command line option to
llvm-pdbdump, which dumps all addresses assuming the module has
loaded at the specified address.
Additionally, this patch adds an option to llvm-pdbdump to support
dumping of public symbols (i.e. symbols with external linkage).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236342 91177308-0d34-0410-b5e6-96231b3b80d8
option to print the archive headers using raw numeric values. Also add the -archive-member-offsets
for use with these to also trigger printing of the offset of the archive member from the start
of the archive.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236252 91177308-0d34-0410-b5e6-96231b3b80d8
print the Objective-C runtime meta data for Mach-O files.
There are three types of Objective-C runtime meta data, Objc2 64-bit,
Objc2 32-bit and Objc1 32-bit. This prints the first of these types. The
changes to print the others will follow next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233840 91177308-0d34-0410-b5e6-96231b3b80d8
A while ago llvm-cov gained support for clang's instrumentation based
profiling in addition to its gcov support, and subcommands were added
to choose which behaviour to use. When no subcommand was specified, we
fell back to gcov compatibility with a warning that a subcommand would
be required in the future. Now, we require the subcommand.
Note that if the basename of llvm-cov is gcov (via symlink or
hardlink, for example), we still use the gcov compatible behaviour
with no subcommand required.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233132 91177308-0d34-0410-b5e6-96231b3b80d8
It seems one windows bot fails since I added ilne table linking to
llvm-dsymutil (see r232333 commit thread).
Disable the affected tests until I can figure out what's happening.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233130 91177308-0d34-0410-b5e6-96231b3b80d8
Otherwise the tests would fail if the default was not elf_x86_64.
This fixes PR22966.
Patch by H.J. Lu!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233124 91177308-0d34-0410-b5e6-96231b3b80d8
This works in a similar way to the gold plugin tests. We search for a compatible
linker on $PATH and use it to run tests against our just-built libLTO. To start
with, test the just added opt level functionality.
Differential Revision: http://reviews.llvm.org/D8472
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232785 91177308-0d34-0410-b5e6-96231b3b80d8
This replaces the -no-color flag with a -color={auto|always|never}
option, with auto as the default, which is much saner.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232693 91177308-0d34-0410-b5e6-96231b3b80d8
This makes the reader check the endianness of the object file its
given and behave appropriately. For the test I dug up a really old
linker and created a ppc-apple-darwin file for llvm-cov to read.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232422 91177308-0d34-0410-b5e6-96231b3b80d8
to print the Mach-O dynamic shared libraries used by a linked image or the
library id of a shared library.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232406 91177308-0d34-0410-b5e6-96231b3b80d8
This still doesn't actually work correctly for big endian input files,
but since these tests all use little endian input files they don't
actually fail. I'll be committing a real fix for big endian soon, but
I don't have proper tests for it yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232354 91177308-0d34-0410-b5e6-96231b3b80d8
This code was casting regions of a memory buffer to a couple of
different structs. This is wrong in a few ways:
1. It breaks aliasing rules.
2. If the buffer isn't aligned, it hits undefined behaviour.
3. It completely ignores endianness differences.
4. The structs being defined for this aren't specifying their padding
properly, so this doesn't even represent the data properly on some
platforms.
This commit is mostly NFC, except that it fixes reading coverage for
32 bit binaries as a side effect of getting rid of the mispadded
structs. I've included a test for that.
I've also baked in that we only handle little endian more explicitly,
since that was true in practice already. I'll fix this to handle
endianness properly in a followup commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232346 91177308-0d34-0410-b5e6-96231b3b80d8
The information gathering part of the patch stores a bit more information
than what is strictly necessary for these 2 sections. The rest will
become useful when we start emitting __apple_* type accelerator tables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232342 91177308-0d34-0410-b5e6-96231b3b80d8
This code comes with a lot of cruft that is meant to mimic darwin's
dsymutil behavior. A much simpler approach (described in the numerous
FIXMEs that I put in there) gives the right output for the vast
majority of cases. The extra corner cases that are handled differently
need to be investigated: they seem to correctly handle debug info that
is in the input, but that info looks suspicious in the first place.
Anyway, the current code needs to handle this, but I plan to revisit it
as soon as the big round of validation against the classic dsymutil is
over.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232333 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-vtabledump has grown enough functionality not related to vtables
that it deserves a name which is more descriptive.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232301 91177308-0d34-0410-b5e6-96231b3b80d8
The debug map embedded by ld64 in binaries conatins function sizes.
These sizes are less precise than the ones given by the debug information
(byte granularity vs linker atom granularity), but they might cover code
that is referenced in the line table but not in the DIE tree (that might
very well be a compiler bug that I need to investigate later).
Anyway, extracting that information is necessary to be able to mimic
dsymutil's behavior exactly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232300 91177308-0d34-0410-b5e6-96231b3b80d8
There is no need to look into the location expressions to transfer them,
the only modification to apply is to patch their base address to reflect
the linked function address.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232267 91177308-0d34-0410-b5e6-96231b3b80d8
This actually shares most of its implementation with the generation
of the debug_ranges (the absence of 'a' is not a typo) contribution
for the unit's DW_AT_ranges attribute.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232246 91177308-0d34-0410-b5e6-96231b3b80d8
Nothing fancy, just a straightforward offset to apply to the original
debug_ranges entries to get them in line with the linked addresses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232232 91177308-0d34-0410-b5e6-96231b3b80d8
We recorded the forward references in the CU that holds the referenced
DIE, but this is wrong as those will get resoled *after* the CU that
holds the reference. Record the references in their originating CU along
with a pointer to the remote CU to be able to compute the fixed up
offset at the right time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232193 91177308-0d34-0410-b5e6-96231b3b80d8
They need to be handled specifically as they could vary pretty
widely depending on how the linker moves functions around.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232192 91177308-0d34-0410-b5e6-96231b3b80d8
The typo got unnoticed because we were testing only on Dwarf 2. Add a
Dwarf4 test that exercises the code path, and also tests some newer
FORMs that the other test doesn't cover.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232191 91177308-0d34-0410-b5e6-96231b3b80d8
Similar to gep (r230786) and load (r230794) changes.
Similar migration script can be used to update test cases, which
successfully migrated all of LLVM and Polly, but about 4 test cases
needed manually changes in Clang.
(this script will read the contents of stdin and massage it into stdout
- wrap it in the 'apply.sh' script shown in previous commits + xargs to
apply it over a large set of test cases)
import fileinput
import sys
import re
rep = re.compile(r"(getelementptr(?:\s+inbounds)?\s*\()((<\d*\s+x\s+)?([^@]*?)(|\s*addrspace\(\d+\))\s*\*(?(3)>)\s*)(?=$|%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|zeroinitializer|<|\[\[[a-zA-Z]|\{\{)", re.MULTILINE | re.DOTALL)
def conv(match):
line = match.group(1)
line += match.group(4)
line += ", "
line += match.group(2)
return line
line = sys.stdin.read()
off = 0
for match in re.finditer(rep, line):
sys.stdout.write(line[off:match.start()])
sys.stdout.write(conv(match))
off = match.end()
sys.stdout.write(line[off:])
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232184 91177308-0d34-0410-b5e6-96231b3b80d8
using numeric values and not their symbolic constant names.
The routines that print Mach-O stuff already had a verbose parameter and this
change is just changing the passing true to passing !NonVerbose. With just a
couple of fixes and a bunch of test case updates.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232182 91177308-0d34-0410-b5e6-96231b3b80d8
