This is not a new answer per se, but an update to those that precede it. denis.gz suggests that perhaps there's a bug in Xcode or its lldb whereby its python interpreter cannot find the module pygdbmi. This is sort of my experience as well, because it didn't work for me either, but the folks who answered this question Why does "pip install" inside Python raise a SyntaxError? had some interesting ideas about how to run pip from within a python interpreter. Why would you want to do this, especially when you would have to quit that session anyway to import the installed module? Because the Xcode lldb Python interpreter is an entire environment onto itself, with its own sys.path, pointing entirely within the Xcode.app package. That's why it can't "see" your installed version of pygdbmi. One can argue about whether this is a bug, but it begs for some solutions, because pygdbmi is required by Qt's lldbbridge.py tool. I'm sure denis.gz's suggestion of copying the installed module from where pip installed it to within the contents of the Qt Creator.app bundle would work, but that didn't sit too well with me, so I looked for other solutions. When lldb is active within an Xcode debug session, you can fire up an interactive interpreter, exactly like the experience of using python from the command line, by using the lldb command script. You are then running a python interpreter within Xcode's lldb python environment. Using the solution that was suggested by the answerer of the above SO question, you can install directly into this environment by the following sequence within the lldb python interpreter -
import pip._internal as pip
pip.main([ "install", "pygdbmi" ])
Now pygdbmi is tucked away within the Xcode's bundle and is accessible to all lldb python. Now that's cool and all, but it's really not much better than copying the installed pygdbmi into Qt Creator.app's bundle. If you were to update your Xcode (and how often does THAT happen?), this fix would probably not stick any more than when updating Qt Creator. So something I thought of after (but haven't tried yet), is the following: you can run a script in lldb python from the lldb command line with something like the following that you could put in your .lldbinit file -
script -l python -- sys.path += [ "directory/with/your/modules" ]
The path given will be outside of the Xcode bundle, and Xcode might nix this, but there's a setting for Xcode that says something about relaxing the "sanitary" build system model and allowing stuff from the larger environment in. If you were to use that, I feel confident the above would do the trick in the best way possible.
Edit:
Towards the end, I suggested a third path available by updating your .lldbinit file to augment the sys.path variable. I tried it, and it worked. First a correction from above. It is not wrong, but is unnecessary to import the pip in the way described above (import pip._internal as pip) to get access to the main method. It is sufficient to simply import pip. The single line I added to my .lldbinit file was -
script -l python -- import sys; sys.path += [ "/usr/local/lib/python3.9/site-packages" ]
After that I chose a module that had not been installed in Xcode's environment, but that had been in my larger environment in site-packages - mercurial for a random example. Back in Xcode, I started the script interpreter and was able to import mercurial without a complaint and without any special settings to "warn" Xcode that it's pristine environment was being opened up, so I just wanted to close that loop, having thrown it out there without a working example.
I have read in other answers while researching this, that there can be a per-scheme lldb init file specified somewhere in the scheme settings. I leave finding that as an exercise for the reader, but that might be a good place to play with these options as well.
