[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.
Welcome to the LLVM project!
This repository contains the source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.
The LLVM project has multiple components. The core of the project is itself called “LLVM”. This contains all of the tools, libraries, and header files needed to process intermediate representations and convert them into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer.
C-like languages use the Clang frontend. This component compiles C, C++, Objective-C, and Objective-C++ code into LLVM bitcode -- and from there into object files, using LLVM.
Other components include: the libc++ C++ standard library, the LLD linker, and more.
Consult the Getting Started with LLVM page for information on building and running LLVM.
For information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.
Join the LLVM Discourse forums, Discord chat, LLVM Office Hours or Regular sync-ups.
The LLVM project has adopted a code of conduct for participants to all modes of communication within the project.