labath added a comment. I haven't looked at the new version of the patch yet, partly because I'm busy (sorry), and partly because I'm not sure we have reached a consensus yet (or at least, I don't know what that consensus is).
Here's some questions/comments to what was earlier said, as I try to figure out what's going on. In D82863#2311196 <https://reviews.llvm.org/D82863#2311196>, @omjavaid wrote: > Furthermore, GDB keeps a list of target descriptions for every combination of > (vq, pauth) where pauth is flag telling if pointer authentication feature is > supported while vq is vector length quad (multiples of 128bits). > https://sourceware.org/git?p=binutils-gdb.git;a=blob;f=gdb/aarch64-tdep.c;h=cbc7038dbba9472a12a3ae927bbb0937b10b2bdd;hb=HEAD#l3284 > > On gdbserver side similar to what is proposed for LLDB, GDB also exchanges > vector length information using expedited registers list and updates target > descriptions based on vg (vector granule register) value. > https://sourceware.org/git?p=binutils-gdb.git;a=blob;f=gdbserver/linux-aarch64-tdesc.cc;h=897fbb43bd28ddf44c69d4162dda43c2589b060f;hb=HEAD#l35 So you're saying that gdb will obtain the vg value from gdbserver and then lookup the proper target.xml description in the set of hardcoded xmls, is that right? Does that mean that gdb will never send the qXfer:target.xml packet on aarch64? Or, it will send it, but then ignore/override the received data with the hardcoded xml ? In D82863#2313676 <https://reviews.llvm.org/D82863#2313676>, @jasonmolenda wrote: > (about g packets...) they cause so many problems if there is a > mis-coordination between the remote stub and lldb, I never want to stop the > remote stub from providing those offsets. I am not sure how to interpret this in the context of SVE registers. The stub cannot send the offsets of those, as their size/offset might change depending on their configuration. Are we saying that we want the stub to send the offsets all registers _except_ SVE (and we hand-compute their offsets on the client)? That might also be tricky because we'd also need to change the offsets of registers that come _after_ the SVE regs. Unless of course, we make sure SVE regs come last, but that imposes some constraints on future registers sets. I suppose we might be able to say that all variable-length or otherwise-funny registers must come last. Another option would be to reserve enough space in the g packet to never have to move other registers due to the another register changing size. That would be nice, though it might pose a problem for stubs that want to be compatible with both gdb and lldb. Unless gdb is doing the same thing that is (is gdb doing the same thing?). CHANGES SINCE LAST ACTION https://reviews.llvm.org/D82863/new/ https://reviews.llvm.org/D82863 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
