labath added a comment. In D134041#3806994 <https://reviews.llvm.org/D134041#3806994>, @jasonmolenda wrote:
> 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. Thanks for jumping in Jason. I forgot about the size field. I think that we need that as well. As for the offset, how do the Mach-O core files work? Are all registers placed into a single note segment? (so that an "offset" is well-defined). In elf, the registers are scattered in multiple notes (roughly according to register sets), and we need to (arbitrarily) concatenate them so that a single offset value is meaningful. But what this really confirms to me that the notion of "static" register info lists is just not sufficient any more. > 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. That's interesting, but I think we should actually be in a fairly good shape for that now, since in the case of ARM SVE, we can have each thread configure the scalable registers with a different size. > 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). Seems reasonable to me. 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
