jasonmolenda added a comment. In D134041#3805941 <https://reviews.llvm.org/D134041#3805941>, @labath wrote:
> In D134041#3805034 <https://reviews.llvm.org/D134041#3805034>, @DavidSpickett > wrote: > >>> That said I would *love* is someone changed the RegisterInfo structs into >>> something saner, but I think that will need to be more elaborate than >>> simply stuffing a std::vector member into it. I can give you my idea of how >>> this could work, if you're interested in trying this out. >> >> Sure I'd be interested in that. I've just been hacking on this small part of >> it so I don't have the full picture yet. > > I think that part of the problem is that nobody has a full picture of how > RegisterInfos work anymore. :) > > I don't claim to have this fully thought out, but the idea goes roughly like > this. For the past few years, we've been moving towards a world where LLDB is > able to fill in lots of details about the target registers. I think we're now > at a state where it is sufficient for the remote stub to specify the register > name and number, and lldb will be able to fill on most of the details about > that register: EH/DWARF/"generic" numbers, subregisters, etc. However, this > code is only invoked when communicating remote stub -- not for core files. > On one hand, this kind of makes sense -- for core files, we are the source of > the register info, so why wouldn't we provide the complete info straight away? An aside, I'm working with a group inside apple that has a JTAG style debugger that can access not only the normal general purpose registers/floating point/vector registers, but control registers like AArch64's MDSCR_EL1 as one example. I haven't figured out the best format for them to express this information in a Mach-O corefile yet, but I am thinking towards a Mach-O LC_NOTE where they embed an XML register description for all the registers they can provide (and it will require that size and maybe offset are explicitly specified, at least), and a register context buffer of bytes for all of the registers. lldb would need to augment its list of available registers with this. My vague memory is that they may have different registers available on each core ("thread") so we would need to do this on per-"thread" basis. This is all vague hand-wavy at this point, but they have the information and the debugger users want this information. At some point I'll want the corefile to be able to augment or replace lldb's register information (probably augment). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134041/new/ https://reviews.llvm.org/D134041 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
