- We use DILexicalBlock and DILexicalBlockFile for generation debug info for kotlin inline (macro substituion by nature).
-- Note: DILexicalBlock aren't nested in opposite to inline function in C meaning.
- Changed DICompileUnit generation practise, now it generated for each file.
- added DI LLVM bindings.
Gradle native software plugins adds -I/usr/include that inroduce conflict with our --systemroot flags,
so we had to add following hack over it:
/* HACK over gradle 4.4, it adds /usr/include, that affects our --sysroot flag */
toolChains {
clang(Clang) {
eachPlatform {
cppCompiler.withArguments { args ->
args.remove /usr/include
}
}
}
}
`GetValueAsUnsigned` return result as a Python `long`, while *some*
versions of lldb require that an `int` is passed to
`ReadCStringFromMemory` down the line. So let's cast result to `int`,
which is 64 bit wide on Python2 anyway.
Also use nicer accessors and a simpler rule to find Kotlin types.
Previously in case type wasn't resolved in codegen (debug info wasn't constructed from IR),
we'd use reference to kotlin.Any? as type, from now we're using forward declaration. What next?
- type parameters... how to deal with?
(cherry picked from commit 579acba659fe52afec638fc00e07a320560bd5fa)
- structured datatypes usable in debug info
- bindings for llvm/Support/Dwarf.h (llvm 3.9) makes easier introducing dwarf constants from LLVM
- added HANDLE_DW_LANG generating sequence DW_LANGs (DW_LANG_Kotlin equals DW_LANG_C89 for now).
- refactoring : g/c typo
- tag (DwarfTag) of the type added as parameter in DICreateReplaceableCompositeType
- binding for creating reference type
- binding for creating array type.
Vasily Levchenko