[Lldb-commits] [PATCH] D55718: [ARC] Basic support in gdb-remote process plugin

[Jason Molenda via Phabricator via lldb-commits]

jasonmolenda added a comment.

In D55718#1443487 <https://reviews.llvm.org/D55718#1443487>, @clayborg wrote:

> As long as the numbers _can_ still come from the GDB server, I am all for that. If they are not supplied, then we use arch defaults. That allows new system/arch bringups where the info might be changing often, and also allows the info to be locked down. The architecture plug-ins are a great place for this. We should also move the breakpoint opcode logic into the architecture plug-ins.


I have no opinion about the RSP stub overriding lldb's definitions - fine by me.  I'm mostly interested in making lldb work better with rando RSP implementations in the wild which often give us very little information about the registers.

Moving the breakpoint opcode into lldb is interesting, would you want to move away from the Z0/z0 packets for setting/removing breakpoints then?  The set-breakpoint packet takes an address and iirc an instruction size.  So on armv7 processors, we know whether we're replacing a 2-byte or 4-byte instruction.  I don't think we want to move the logic of breakpoint setting & clearing into lldb and use generic read/write memory - the RSP stub may know how to clear instruction caches when we're modifying instruction data, for instance.  So we'd make a variation of the z0 packet which takes an address and a byte sequence to put at that address?  tbh it seems like the RSP stub is the correct place for this knowledge, even though we have to provide the hack of "use the 2-byte breakpoint instruction" / "use the 4-byte breakpoint instruction" on targets like armv7 because lldb has the knowledge of the underlying instructions.


Repository:
  rLLDB LLDB

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55718/new/

https://reviews.llvm.org/D55718