[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.

Author: DavidSpickett

lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp

@@ -547,7 +547,23 @@ void ProcessGDBRemote::BuildDynamicRegisterInfo(bool force) {
         assert(reg_info.byte_size != 0);
         registers.push_back(reg_info);
       } else {
-        break; // ensure exit before reg_num is incremented
+        // Only warn if we were offered Target XML and could not use it, and
+        // the qRegisterInfo fallback failed. This is something a user could
+        // take action on by getting an lldb with libxml2.
+        //
+        // It's possible we weren't offered Target XML and qRegisterInfo failed,
+        // but there's no much a user can do about that. It may be the intended
+        // way the debug stub works, so we do not warn for that case.
+        if (response_type == StringExtractorGDBRemote::eUnsupported &&
+            m_gdb_comm.GetQXferFeaturesReadSupported() &&
+            !XMLDocument::XMLEnabled()) {
+          Debugger::ReportWarning(
+              "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.",
+              GetTarget().GetDebugger().GetID());
+        }
+        break;
       }
     } else {
       break;