llvm-project

6b040b4b - [lldb] Issue a warning when Target XML should have been used but we do not have libxml2 (#170663)

[lldb] Issue a warning when Target XML should have been used but we do not have libxml2 (#170663) If you connect lldb without libxml2 enabled, to a debug stub, that server may offer Target XML but lldb will not use it. This often causes incorrect or missing registers. So much so that I think users should be made aware of this so they can find an lldb with libxml2 enabled. This warning will only be printed when: * The debug server offered us Target XML but lldb does not have libxml2, and - * qRegisterInfo was not supported by the debug server. This means that (lldb without libxml2) -> (lldb-server or debugserver) will not warn as we'll fall back to qRegisterInfo. All that's potentially missing is advanced register formatting information, which most people won't notice is missing anyway. If they do, the logs contain information about this. If you connect (lldb without libxml2) > (gdbserver, or a stub inspired by it) you will see this warning. As they do not support qRegisterInfo. ``` $ ./bin/lldb /tmp/test.o -o "gdb-remote 1234" (lldb) target create "/tmp/test.o" Current executable set to '/tmp/test.o' (aarch64). (lldb) gdb-remote 1234 warning: the debug server supports Target Description XML but LLDB does not have XML parsing enabled. Using "qRegisterInfo" was also not possible. Register information may be incorrect or missing. ``` When qRegisterInfo is not supported, there are 4 possible situations. 1. The debug server offered Target XML and we do not have libxml2 We should warn the user so they can find an lldb with libxml2. 2. The debug server offered Target XML but it was not valid XML Ideally we'd warn here too, but the error handling needs more work to implement this, and there is logging for it if you know where to look. 3. The debug server did not offer Target XML and we have libxml2 4. The debug server did not offer Target XML and we do have libxml2 There's no XML to parse, so no reason to warn. The user is not getting a worse debug experience because we lack libxml2. Their only course of action here would be to replace the debug stub. Given that this occurs a lot with stubs embedded in kernels or debug hardware, they may not have a choice either.