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

[Ramana via lldb-dev]

Thank you Ted for your comments.

On Mon, Sep 18, 2017 at 11:25 PM, Ted Woodward
<ted.woodward at codeaurora.org> wrote:
> 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
>