In lldb, when I try to “target create [invalid_target]”, I got some meaningful error message like:
error: ‘XXX’ doesn’t contain any ‘host’ platform architectures: x86_64h, x86_64, i386
What is the python API to get this from? I tried to check SBTarget.IsValid() and then use SBTarget.GetDescription(eDescriptionLevelVerbose), but that does not return the error message.
The SBDebugger::CreateTarget() call take an "SBError &error" as the last argument. The error will contain any error message:
CreateTarget (const char *filename,
const char *target_triple,
const char *platform_name,
This function is the one that should be used. Any of the "const char *" arguments can be NULL. But typically you want to specify at least the filename. The triple is only really needed if you are debugging files that have more than one architecture or if the file you are debugging doesn't completely specify what you want to debug. The triple can be "x86_64" or more specific like "x86_64-apple-ios". The platform name only needs to be specified if your executable file (ELF file, mach-o file, or other exe format) doesn't have enough information inside of it to extract the triple from the object file. ELF has very sparse information inside of it to help us identify what platform it can/should be used for. You will know if you need to specify the platform if LLDB gets it wrong. To see what happens, try things out from the command line:
(lldb) target create /tmp/a.out
(lldb) target list
* target #0: /tmp/a.out ( arch=x86_64-apple-macosx, platform=host )
We see that the "host" platform was auto selected and the architecture was extracted from the executable as "x86_64-apple-macosx".
To see a list of platform names you can do:
(lldb) platform select <TAB>
So if you have an iOS binary that was targeting a device (not a simulator), you could create your target with:
lldb::SBTarget target = debugger.CreateTarget("/tmp/a.out", "armv7-apple-ios", "remote-ios", false, error);
Ah, I used CreateTargetWithFileAndArch() and missed this one. Feeling embarrassed… Thank you!
Yep, this is legacy API that must stay in because we had it in our API waaayyyy back when and we never remove API once it has made it into a build and someone uses it. We might mark it as deprecated, which we should do to CreateTargetWithFileAndArch and the other function, but we never remove it.