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

[Ramana via lldb-dev]

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 <clayborg at 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.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
>>>
>