On Windows, there are multiple variants of the C runtime that must be
explicitly specified and consistently used from the runtime to the
application. The new `-libc` option allows us to control the linking
phase by correctly embedding the requested library to be linked. It is
made into a required parameter on Windows and will add in the
appropriate flags for the imported C headers as well. This ensures that
the C library is not incorrectly linked.
A workaround in codeview debuginfo generation was to declare a condfail
instruction as inlined to avoid using 0 as an artificial line location.
However, this was done without accounting for scopes that were already
legitimately inlined. So we'd end up with a condfail inlined from
function B into function A and then the IRGen for the condfail was
being given a debugloc claiming to have been inlined again. This was
causing a sitaution where we'd have debug info forfunctionA owning an
instruction which claimed it was owned by a different function.
Fix this by first checking if the `LastScope` was already inlined and,
if so, just used that scope instead.
The fix is to set the DebugCompilationDir when -gsil is used.
Otherwise no debug info is generated if the source file name does not contain a path.
rdar://problem/49796695
When a Swift module built with debug info imports a library without
debug info from a textual interface, the textual interface is
necessary to reconstruct types defined in the library's interface. By
recording the Swift interface files in DWARF dsymutil can collect them
and LLDB can find them.
rdar://problem/49751363
module imports. This is useful when building redistributable static
archives, since any pointers into the CLang module cache won't be
portable.
When using this option the Clang type fallback path in LLDB will be
less useful since DWARF type information from those modules will not
be available unless another object file compiled without the option
imported the same modules.
rdar://problem/48827784
Windows absolute paths are either UNC paths (begin with \\) or are
rooted with a drive letter. Unfortunately, we cannot conditionalise the
path itself on the OS type. On Unices // indicates the alternate root
path as per POSIX. However, Linux does not implement this and // is
treated as /. Use this to create a path that appears to be absolute on
all the targets.
It would be nice to query the clang::SourceManager for the source
location of the clang::Decl in IRGenDebugInfo, but module out-of-date
rebuilds may unload previously loaded clang::Modules and thus also
invalidate source locations pointed to, leading to a use-after-free
here. If this functionality is desired, the source location must be
captured by ClangImporter and stored on the side.
LLDB does not actually make use of this information for non-C++ types
(it is really helpful with debugging the debug info itself, though),
so we can avoid the potential use-after-free and crash by not doing it.
<rdar://problem/48509051>
Currently LLDB calls into ide::getDeclFromMangledSymbolName() to get
to this information and we would like to get rid of this call.
rdar://problem/47798056
This changes the Swift resource directory from looking like
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
x86_64/
Swift.swiftmodule
Swift.swiftdoc
Darwin.swiftmodule
Darwin.swiftdoc
to
lib/
swift/
macosx/
libswiftCore.dylib
libswiftDarwin.dylib
Swift.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
Darwin.swiftmodule/
x86_64.swiftmodule
x86_64.swiftdoc
matching the layout we use for multi-architecture swiftmodules
everywhere else (particularly frameworks).
There's no change in this commit to how Linux swiftmodules are
packaged. There's been past interest in going the /opposite/ direction
for Linux, since there's not standard support for fat
(multi-architecture) .so libraries. Moving the .so search path /down/
to an architecture-specific directory on Linux would allow the same
resource directory to be used for both host-compiling and
cross-compiling.
rdar://problem/43545560
The layouts of resilient value types shipped in the Swift 5 standard library
x and overlays will forever be frozen in time for backward deployment to old
Objective-C runtimes. This PR ensures that even if the layouts of these types
evolve in the future, binaries built to run on the old runtime will continue
to lay out class instances in a manner compatible with Swift 5.
Fixes <rdar://problem/45646886>.
There was only one remaining usage other than in testing tools.
Note that when a declaration mangling was passed in, the old entry
point would (try to) return the type of the declaration.
The new entry point no longer has this behavior. I changed the
bridging-header-first test to run lldb-moduleimport-test with
-decl-from-mangled instead of -type-from-mangled-old to preserve
the behavior of the test.
Also, I removed test/DebugInfo/DumpTypeFromMangledName.swift
completely. This test only covered a handful of cases, and a bunch
of them were declaration manglings rather than type manglings.
The new tests in test/TypeDecoder/ are much more comprehensive.
This applies the same changes from Clang CFE r349065 to the Swift
frontend to unify how filenames, cmpilation directories and absolute
paths in filenames and path remappings are handled.
The LLVM API for the temporary paths behaves differently on Windows and Unix.
Windows always returns the absolute path, and on Unix, you get whatever is in
the environment. Furthermore, windows allows both `\` and `/` as separators.
Normalise the path and make it absolute before doing the comparision to get a
comparable string.
`file` is not available on windows except through GnuWin32, and that
`file` was identifying the ClangModule as an ACB Archive file instead of
a COFF file.
Instead of using `file`, it is easier and more portable to use
llvm-readobj. I also converted the egrep usage into FileCheck while
adding COFF support.
The loading of additional modules by Sema may trigger an out-of-date
PCM rebuild in the Clang module dependencies of the additional
module. A PCM rebuild causes the ModuleManager to unload previously
loaded ASTFiles. For this reason we must use the cached ASTFile
information here instead of the potentially dangling pointer to the
ASTFile that is stored in the clang::Module object.
This fixes a crash in IRGenDebugInfo when generation DIModule context
chains.
rdar://problem/47600180
The -type-from-mangled flag now uses the new API. The -type-from-mangled-old flag
uses the old API, ide::getTypeFromMangledSymbolname().
For now, just change all existing tests to use the -type-from-mangled-old flag;
I'll be adding new tests for the new API shortly.
Swift.UnicodeScalar is a typealias now, and for the TypeDecoder
to work correctly we need to mangle it as a typealias and not as
a struct.
However, we still want to demangle old names that used the
substitution, so don't remove it, instead just skip checking for
a substitution when mangling a typealias.
This does not change the ABI; typealiases are only mangled as
part of debug info.
