[lldb-dev] lldb_private::RegisterContext vs lldb_private::RegisterInfoInterface

[Ted Woodward via lldb-dev]

I recently added Hexagon Linux support to lldb-server; I did what Greg suggested below - subclassed NativeRegisterContextLinux, like the other architectures did. I also added the software breakpoint opcode to NativeProcessLinux. After that, it was just a matter of getting the register accessor functions in NativeRegisterContextLinux_hexagon.cpp correct.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

> -----Original Message-----
> From: lldb-dev [mailto:lldb-dev-bounces at lists.llvm.org] On Behalf Of Greg
> Clayton via lldb-dev
> Sent: Monday, September 18, 2017 10:16 AM
> To: Ramana <ramana.venkat83 at gmail.com>
> Cc: lldb-dev at lists.llvm.org
> Subject: Re: [lldb-dev] lldb_private::RegisterContext vs
> lldb_private::RegisterInfoInterface
> 
> 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.venkat83 at 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 <clayborg at 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 at 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 at lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >>
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev