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

[Pavel Labath via Phabricator via lldb-commits]

labath 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.


Which part of the information that Jason mentioned do you expect to change during bringup?

- eh/debug_frame numbers aren't something that the stub can unilaterally change, as it needs to match what the compiler thinks. Since we're not going to get the compiler to ask our stub about the eh_frame numbers, I don't see the problem in hardcoding that info. TBE, the best way would be no not even hardcode that info but ask llvm about these things. That way if somebody develops the whole platform (compiler, abi, and everything), and uses llvm technology everywhere, he would just need to change the numbers once and recompile -- lldb, lldb-server and clang would automatically pick that up
- the ABI is also something that needs to match with the compiler, and is something that is largely irrelevant for the operation of the rsp stub
- how to print a register is also completely irrelevant for the stub, and (IMO) also largely unimportant during early bringup stages

The things I can see changing frequently while developing a stub for a new platform are the register numbers and g packet offsets, but that's already something that Jason included in the list of things that the stub should provide.


Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D55718