so the lookup works as expected after prepending the oso-prepend-path.
This manifested only on Windows, because "/" is not a relative path there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@248423 91177308-0d34-0410-b5e6-96231b3b80d8
When building LLVM as a (potentially dynamic) library that can be linked against
by multiple compilers, the default triple is not really meaningful.
We allow to explicitely set it to an empty string when configuring LLVM.
In this case, said "target independent" tests in the test suite that are using
the default triple are disabled by matching the newly available feature
"default_triple".
Reviewers: probinson, echristo
Differential Revision: http://reviews.llvm.org/D12660
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247775 91177308-0d34-0410-b5e6-96231b3b80d8
We already fail with 'No such file or directory' when we try to open
the file -- if that doesn't exist. Also add a test to verify this behavior.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247744 91177308-0d34-0410-b5e6-96231b3b80d8
This is a follow up to r247518.
As a general note, I think we could do a much better job testing for
error conditions in tools. I already anticipated in a previous mail,
but while implementing this I noticed that the code coverage we have
for error checking is pretty low. I can arbitrarily remove checks from
several tools and the suite still passes.
Differential Revision: http://reviews.llvm.org/D12846
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247582 91177308-0d34-0410-b5e6-96231b3b80d8
When cloning the debug info for a function that hasn't been linked,
strip the DIEs from all location attributes that wouldn't contain any
meaningful information anyway.
This kind of situation can happen when a function got discarded by the
linker, but its debug information is still wanted in the final link
because it was marked as required as some other DIE dependency. The easiest
way to get into that situation is to have using directives. They get
linked unconditionally, but their targets might not always be present.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@247386 91177308-0d34-0410-b5e6-96231b3b80d8
If ld.gold is configured without --enable-thread, ld.gold might not load libpthread.so.
Preloading LLVMgold.so loads also libpthread.so.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246739 91177308-0d34-0410-b5e6-96231b3b80d8
With a fix for big endian machines. Thanks to Daniel Sanders for the debugging!
Original commit message:
The binaries containing the linked DWARF generated by dsymutil are not
standard relocatable object files like emitted did previsously. They should be
dSYM companion files, which means they have a different file type in the
header, but also a couple other peculiarities:
- they contain the segments and sections from the original binary in their
load commands, but not the actual contents. This means they get an address
and a size, but their offset is always 0 (but these are not virtual sections)
- they also conatin all the defined symbols from the original binary
This makes MC a really bad fit to emit these kind of binaries. The approach
that was used in this patch is to leverage MC's section layout for the
debug sections, but to use a replacement for MachObjectWriter that lives
in MachOUtils.cpp. Some of the low-level helpers from MachObjectWriter
were reused too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246673 91177308-0d34-0410-b5e6-96231b3b80d8
For me,
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7deb0dc in _dl_fixup () from /lib64/ld-linux-x86-64.so.2
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246641 91177308-0d34-0410-b5e6-96231b3b80d8
If a symbol is marked as "data", the symbol should be exported
with __imp_ prefix. Previously, the symbol was exported as-is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246532 91177308-0d34-0410-b5e6-96231b3b80d8
This testcase required 2 copies of the same file, and the second
copy was missing. It was currently working because of a bug I'm
about to fix.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246411 91177308-0d34-0410-b5e6-96231b3b80d8
The fix is trivial (The actual patch is 2 lines, but as it changes
indentation it looks like more).
clang does not produce this kind of (slightly bogus) debug info
anymore, thus I had to rely on a hand-crafted assembly test to trigger
that case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246410 91177308-0d34-0410-b5e6-96231b3b80d8
The value of an inlined subprogram low_pc attribute should not
get relocated, but it can happen that it matches the enclosing
function's start address and thus gets the generic treatment.
Special case it to avoid applying the PC offset twice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246406 91177308-0d34-0410-b5e6-96231b3b80d8
This option dumps the STAB entries that define the debug map(s)
stored in the input binaries, and then exits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246403 91177308-0d34-0410-b5e6-96231b3b80d8
As a follow-up to r246098, require `DISubprogram` definitions
(`isDefinition: true`) to be 'distinct'. Specifically, add an assembler
check, a verifier check, and bitcode upgrading logic to combat testcase
bitrot after the `DIBuilder` change.
While working on the testcases, I realized that
test/Linker/subprogram-linkonce-weak-odr.ll isn't relevant anymore. Its
purpose was to check for a corner case in PR22792 where two subprogram
definitions match exactly and share the same metadata node. The new
verifier check, requiring that subprogram definitions are 'distinct',
precludes that possibility.
I updated almost all the IR with the following script:
git grep -l -E -e '= !DISubprogram\(.* isDefinition: true' |
grep -v test/Bitcode |
xargs sed -i '' -e 's/= \(!DISubprogram(.*, isDefinition: true\)/= distinct \1/'
Likely some variant of would work for out-of-tree testcases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246327 91177308-0d34-0410-b5e6-96231b3b80d8
This patch includes a fix for a llvm-readobj test. With this patch,
the tool does no longer print out COFF headers for the short import
file, but that's probably desirable because the header for the short
import file is dummy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246283 91177308-0d34-0410-b5e6-96231b3b80d8
The binaries containing the linked DWARF generated by dsymutil are not
standard relocatable object files like emitted did previsously. They should be
dSYM companion files, which means they have a different file type in the
header, but also a couple other peculiarities:
- they contain the segments and sections from the original binary in their
load commands, but not the actual contents. This means they get an address
and a size, but their offset is always 0 (but these are not virtual sections)
- they also conatin all the defined symbols from the original binary
This makes MC a really bad fit to emit these kind of binaries. The approach
that was used in this patch is to leverage MC's section layout for the
debug sections, but to use a replacement for MachObjectWriter that lives
in MachOUtils.cpp. Some of the low-level helpers from MachObjectWriter
were reused too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246012 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-dsymutil needs to emit dSYM companion bundles. These are binary files
that replicate some of the orignal binary file properties (sections and
symbols). To get acces to these properties, pass the binary path in the
debug map.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246011 91177308-0d34-0410-b5e6-96231b3b80d8
There was an issue in the test setup because the test requires an arch that
wasn't filtered by the lit.local.cfg, but given the set of bots that failed,
I'm not confident this is the (only) issue. So this commit also adds more
output to the test to help me track down the failure if it happens again.
Original commit message:
[dsymutil] Rewrite thumb triple names in user visible messages.
We autodetect triples from the input file(s) while reading the mach-o debug map.
As we need to create a Target from those triples, we always chose the thumb
variant (because the arm variant might not be 'instantiable' eg armv7m). The
user visible architecture names should still be 'arm' and not 'thumb' variants
though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245988 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r245960.
Multiple bots are failing on the new test. It seemd like llvm-dsymutil exits with an error. Investigating.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245964 91177308-0d34-0410-b5e6-96231b3b80d8
We autodetect triples from the input file(s) while reading the mach-o debug map.
As we need to create a Target from those triples, we always chose the thumb
variant (because the arm variant might not be 'instantiable' eg armv7m). The
user visible architecture names should still be 'arm' and not 'thumb' variants
though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245960 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds all the refactored tests in new files, the old
tests will be removed by a followup commit.
Thanks to D. Blaikie for all the feedback.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245803 91177308-0d34-0410-b5e6-96231b3b80d8
The module splitter splits a module into linkable partitions. It will
be used to implement parallel LTO code generation.
This initial version of the splitter does not attempt to deal with the
somewhat subtle symbol visibility issues around module splitting. These
will be dealt with in a future change.
Differential Revision: http://reviews.llvm.org/D12132
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245662 91177308-0d34-0410-b5e6-96231b3b80d8
These tests pass with Windows 7 x64 + MSYS2. I'll see if the bots like
them as well and disable the failing ones.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@244572 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This makes it so that reports symbolized after the fact with
llvm-symbolizer are more similar to the ones we generate at runtime with
in-process dbghelp.
Reviewers: samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11785
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@244512 91177308-0d34-0410-b5e6-96231b3b80d8
I looked into adding a warning / error for this to FileCheck, but there doesn't
seem to be a good way to avoid it triggering on the instances of it in RUN lines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@244481 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-dsymutil has to be able to process debug info produced by other compilers
which use different line table settings. The testcase wasn't generated by
another compiler, but by a modified clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@244319 91177308-0d34-0410-b5e6-96231b3b80d8
Adrian Prantl