Thank you so much Greg for your comments. > What architecture and os are you looking to support?
The OS is Linux and the primary use scenario is remote debugging. Basically http://lists.llvm.org/pipermail/lldb-dev/2017-June/012445.html is what I am trying to achieve and unfortunately that query did not get much attention of the members. Thanks, Ramana On Mon, Sep 18, 2017 at 8:46 PM, Greg Clayton <clayb...@gmail.com> wrote: > When supporting a new architecture, our preferred route is to modify > lldb-server (a GDB server binary that supports native debugging) to support > your architecture. Why? Because this gets you remote debugging for free. If > you go this route, then you will subclass a > lldb_private::NativeRegisterContext and that will get used by lldb-server > (along with lldb_private::NativeProcessProtocol and > lldb_private::NativeThreadProtocol). If you are adding a new architecture to > Linux, then you will likely just need to subclass NativeRegisterContext. > > The other way to go is to subclass lldb_private::Process, > lldb_private::Thread and lldb_private::RegisterContext. > > The nice thing about the lldb_private::Native* subclasses is that you only > need to worry about native support. You can use #ifdef and use system header > files, where as the non native route, those classes need to be able to debug > remotely and you can't rely on system headers (lldb_private::Process, > lldb_private::Thread and lldb_private::RegisterContext) since they can be > compiled on any system for possibly local debugging (if current > arch/vendor/os matches the current system) and remote (if you use lldb-server > or another form for RPC). > > I would highly suggest getting going the lldb-server route as then you can > use system header files that contain the definitions of the registers and you > only need to worry about the native architecture. Linux uses ptrace and has > much the the common code filtered out into correct classes (posix ptrace, > linux specifics, and more. > > What architecture and os are you looking to support? > > Greg Clayton > >> On Sep 16, 2017, at 6:28 AM, Ramana <ramana.venka...@gmail.com> wrote: >> >> Thank you Greg for the detailed response. >> >> Can you please also shed some light on the NativeRegisterContext. When >> do we need to subclass NativeRegisterContext and (how) are they >> related to RegisterContext<OS>_<Arc >> It appears that not all architectures having >> RegisterContext<OS>_<Arch> have sub classed NativeRegisterContext. >> >> Regards, >> Ramana >> >> On Thu, Sep 14, 2017 at 9:02 PM, Greg Clayton <clayb...@gmail.com> wrote: >>> Seems like this class was added for testing. RegisterInfoInterface is a >>> class that creates a common API for getting lldb_private::RegisterInfo >>> structures. >>> >>> A RegisterContext<OS>_<Arch> class uses one of these to be able to create a >>> buffer large enough to store all registers defined in the >>> RegisterInfoInterface and will actually read/write there registers to/from >>> the debugged process. RegisterContext also caches registers values so they >>> don't get read multiple times when the process hasn't resumed. A >>> RegisterContext subclass is needed for each architecture so we can >>> dynamically tell LLDB what the registers look like for a given >>> architecture. It also provides abstractions by letting each register define >>> its registers numbers for Compilers, DWARF, and generic register numbers >>> like PC, SP, FP, return address, and flags registers. This allows the >>> generic part of LLDB to say "I need you to give me the PC register for this >>> thread" and we don't need to know that the register is "eip" on x86, "rip" >>> on x86_64, "r15" on ARM. RegisterContext classes can also determine how >>> registers are read/written: one at a time, or "get all general purpose >>> regs" and "get all FPU regs". So if someone asks a RegisterContext to read >>> the PC, it might go read all GPR regs and then mark them all as valid in >>> the register context buffer cache, so if someone subsequently asks for SP, >>> it will be already cached. >>> >>> So RegisterInfoInterface defines a common way that many RegisterContext >>> classes can inherit from in order to give out the >>> lldb_private::RegisterInfo (which is required by all subclasses of >>> RegisterContext) info for a register context, and RegisterContext is the >>> one that actually will interface with the debugged process in order to >>> read/write and cache those registers as efficiently as possible for the >>> current program being debugged. >>> >>>> On Sep 12, 2017, at 10:59 PM, Ramana via lldb-dev >>>> <lldb-dev@lists.llvm.org> wrote: >>>> >>>> Hi, >>>> >>>> When deriving RegisterContext<OS>_<Arch>, why some platforms (Arch+OS) >>>> are deriving it from lldb_private::RegisterContext while others are >>>> deriving from lldb_private::RegisterInfoInterface or in other words >>>> how to decide on the base class to derive from between those two and >>>> what are the implications? >>>> >>>> Thanks, >>>> Ramana >>>> _______________________________________________ >>>> lldb-dev mailing list >>>> lldb-dev@lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
