lldb reports wrong ABI

[cristianadam]

At https://bugreports.qt.io/browse/QTCREATORBUG-26247 I reported that Qt Creator detects x86-windows-msvc2015-pe-64bit as ABI, which might explain why the debugged program crashes with:

 eERROR: Lldb stderr:  #0 0x00007ffab4913933 clang::CreateMicrosoftCXXABI(clang::ASTContext&) (C:\llvm-mingw\bin\libclang-cpp.dll+0x563933)
e #1 0x00007ffab45e0e95 clang::ASTContext::getTypeInfoImpl(clang::Type const*) const (C:\llvm-mingw\bin\libclang-cpp.dll+0x230e95)
e #2 0x00007ffab45e225b clang::ASTContext::getTypeInfo(clang::Type const*) const (C:\llvm-mingw\bin\libclang-cpp.dll+0x23225b)
e #3 0x00007ffadae4e17a PyInit__lldb (C:\llvm-mingw\bin\liblldb.dll+0x6be17a)

See the linked issue for more stacktrace.

This might be related to https://bugs.llvm.org/show_bug.cgi?id=51433

[mstorsjo]

Thanks for the report! It does indeed sound like that could be a probable cause, especially given the CreateMicrosoftCXXABI crash location.

The fact that things crash sounds like an issue to look into, regardless of the fix to use the right C++ ABI. The PoC patch in the linked bug report does sound like it could help.

Do you happen to know if it's possible to trigger this from the LLDB CLI? That'd make it a fair bit easier to look into for me.

[cristianadam]

Apparently one can use the command line to debug things. See https://github.com/qt-creator/qt-creator/tree/master/share/qtcreator/debugger

Or for LLDB (.lldbinit or directly in the LLDB interpreter):

      command script import <path/to/qtcreator>/share/qtcreator/debugger/lldbbridge.py

This will add LLDB summary providers for all the Qt types in a new type category named 'Qt'.



In order to hook a new debugger backend into this "common pretty printing system",
the backend should expose a Python API containing at least the following:


class Value:
    name() -> string                      # Name of this thing or None
    type() -> Type                        # Type of this value
    asBytes() -> bytes                    # Memory contents of this object, or None
    address() -> int                      # Address of this object, or None
    dereference() -> Value                # Dereference if value is pointer,
                                          # remove reference if value is reference.
    hasChildren() -> bool                 # Whether this object has subobjects.
    expand() -> bool                      # Make sure that children are accessible.
    nativeDebuggerValue() -> string       # Dumper value returned from the debugger

    childFromName(string name) -> Value   # (optional)
    childFromField(Field field) -> Value  # (optional)
    childFromIndex(int position) -> Value # (optional)


class Type:
    name() -> string                      # Full name of this type
    bitsize() -> int                      # Size of type in bits
    code() -> TypeCodeTypedef
            | TypeCodeStruct
            | TypeCodeVoid
            | TypeCodeIntegral
            | TypeCodeFloat
            | TypeCodeEnum
            | TypeCodePointer
            | TypeCodeArray
            | TypeCodeComplex
            | TypeCodeReference
            | TypeCodeFunction
            | TypeCodeMemberPointer
            | TypeCodeUnresolvable

    unqualified() -> Type                 # Type without const/volatile
    target() -> Type                      # Type dereferenced if it is a pointer type, element if array etc
    stripTypedef() -> Type                # Type with typedefs removed
    fields() -> [ Fields ]                # List of fields (member and base classes) of this type

    templateArgument(int pos, bool numeric) -> Type or int   # (optional)

class Field:
    name() -> string                      # Name of member, None for anonymous items
    isBaseClass() -> bool                 # Whether this is a base class or normal member
    type() -> Type                        # Type of this member
    parentType() -> Type                  # Type of class this member belongs to
    bitsize() -> int                      # Size of member in bits
    bitpos() -> int                       # Offset of member in parent type in bits



parseAndEvaluate(string: expr) -> Value   # or None if not possible.
lookupType(string: name) -> Type          # or None if not possible.
listOfLocals() -> [ Value ]               # List of items currently in scope.
readRawMemory(ULONG64 address, ULONG size) -> bytes # Read a block of data from the virtual address space

I have never used lldb from command line though.

[mstorsjo]

Right... but in Qt Creator, what debugging action do you do to trigger it - does it happen just right away when starting debugging without any specific UI interaction? (In that case, I presume it worked on simpler test cases before, so it breaks when the debugged app uses e.g. specific language features?) Or does debugging start off working and things crash when you e.g. inspect a variable that contains a nontrivial C++ object, or something like that?

I.e., if I download the Qt Creator kit you built in #73 (comment), how do I go about to reproduce the bug?

[cristianadam]

At https://bugreports.qt.io/browse/QTCREATORBUG-26247 I had a breakpoint at cmakeparser.cpp:61 in function CMakeParser::handleLine . This would require loading a CMake project and running CMake for the project.

But it reproduces also with cmakeproject.cpp:57 in CMakeProject::CMakeProject which would only require loading a CMake project.

I think at #73 I got lucky and had a breakpoint without any function parameters, and I only looked at the debugger view and was happy about it. I didn't do a more extensive debugging session.

[mstorsjo]

Reopening until the fix is available in an actual release.

[mstorsjo]

A prerelease with LLVM 15.0.0 RC1 is now out, where this issue should be fixed.