DavidSpickett wrote: > Thinking about it, it'd probably make more sense to add these as defined > names in the dwarf & eh_frame enum lists, and possibly add them to the > aarch64 GPRs.
These being the ones numbered >= 33, right? > My only concern about adding these to the GPRs in the .h file is that I don't > know if that might be an issue for a NativeHost plugin. All of our live process debugging is "remote" even on localhost, so I guess you mean things like core files? It could create a bunch of `foo = <unavailable>`, depending on what layers are implemented. At least for AArch64 core files, we add register infos based on the availability of the notes. This is more difficult if the registers are in theory "general" but don't have a special place to be stored. You can always try it out and see what normal sessions look like after the changes. > With a gdb-remote protocol, we ask the remote stub what registers it supports > (target.xml, or qRegisterInfo). It may only provide a register name and > number -- and we want to supplement the size, format, and any additional info > like eh_frame/dwarf regno, from the .h file definitions. I don't think having > extra registers in that register infos array is a problem with gdb remote > serial protocol sessions. Sounds right. The only thing I know we cannot handle is registers coming and going between steps, which is not applicable to these basic system registers. (well, we can "handle" them by marking them unavailable, but it's not great) https://github.com/llvm/llvm-project/pull/183860 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
