clayborg added a comment. In D134041#3811289 <https://reviews.llvm.org/D134041#3811289>, @labath wrote:
> 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. Mach-o core files have registers in load commands (LC_THREAD) I believe. Within this, there is a register set flavor enum (GPR, FPU, EXC, DBG, etc), and then all of the registers are expected to be understood by whomever loads them and are given as here are N bytes for GPR. So something like: LC_THREAD , CMDSIZE FLAVOR, COUNT, BYTES FLAVOR, COUNT, BYTES ZERO A Zero for flavor terminates the register data for a thread. >> 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. Typical core files seem to mostly have register data hard coded and the consumers are supposed to know exactly what is in register data (ELF core, mach-o core and minidump). Anything that gets us closer to our lldb-server workflow where we dynamically can figure out what the registers are is a good thing. 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
