On Mon, 2021-04-19 at 16:29 -0700, Greg Clayton wrote: > > I think the first blocker towards this project are existing > > implementation bugs in LLDB. For example, the vFile implementation is > > documented as using incorrect data encoding and open flags. This is not > > something that can be trivially fixed without breaking compatibility > > between different versions of LLDB. > > We should just fix this bug in LLDB in both LLDB's logic and lldb-server > IMHO. We typically distribute both "lldb" and "lldb-server" together so this > shouldn't be a huge problem.
Hmm, I've focused on this because I recall hearing that OSX users sometimes run new client against system server... but now I realized this isn't relevant to LLGS ;-). Still, I'm happy to do things the right way if people feel like it's needed, or the easy way if it's not. > The other main issue LLDB has when using other GDB servers is the dynamic > register information is not enough for debuggers to live on unless there is > some hard coded support in the debugger that can help fill in register > numberings. The GDB server has its own numbers, and that is great, but in > order to truly be dynamic, we need to know the compiler register number (such > as the reg numbers used for .eh_frame) and the DWARF register numbers for > debug info that uses registers numbers (these are usually the same as the > compiler register numbers, but they do sometimes differ (like x86)). LLDB > also likes to know "generic" register numbers like which register it the PC > (RIP for x86_64, EIP for x86, etc), SP, FP and a few more. lldb-server has > extensions for this so that the dynamic register info it emits is enough for > LLDB. We have added extra key/value pairs to the XML that is retrieved via > "target.xml" so that it can be complete. See the function in > lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp: > > bool ParseRegisters(XMLNode feature_node, GdbServerTargetInfo &target_info, > GDBRemoteDynamicRegisterInfo &dyn_reg_info, ABISP abi_sp, > uint32_t ®_num_remote, uint32_t ®_num_local); > > There are many keys we added: "encoding", "format", "gcc_regnum", > "ehframe_regnum", "dwarf_regnum", "generic", "value_regnums", > "invalidate_regnums", "dynamic_size_dwarf_expr_bytes" > Yes, this is probably going to be the hardest part. While working on plugins, I've found LLDB register implementation very hard to figure out, especially that the plugins seem to be a mix of new, old and older solutions to the same problem. We will probably need more ground-level design changes too. IIRC lldb sends YMM registers as a whole (i.e. with duplication with XMM registers) while GDB sends them split like in XSAVE. I'm not yet sure how to handle this best -- if we don't want to push the extra complexity on plugins, it might make sense to decouple the packet format from the data passed to plugins. -- Best regards, Michał Górny _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
