[lldb-dev] [RFC] OS awareness in LLDB

[Alexander Polyakov via lldb-dev]

>
> Are you asking for the ability to create external native plug-ins instead
> of the python OS plug-in interface?

The main idea is to have one common native/Python OS plug-in that can be
extended with new architectures and operating systems.

What is missing from the python OS plug-in interface here? A register
> context represents all of the registers so I don't follow what you mean
> with what is stated above about asking for a register context by index. So
> you want multiple architectures to show up in the same process? If so this
> will require many changes to LLDB as each thread currently is assumed to
> have the same architecture as the process.

The *RegisterContext *already provides register info, so having it in a
public API makes it possible to get rid of duplicating register info
definitions (example
<https://github.com/apple/darwin-xnu/blob/a449c6a3b8014d9406c2ddbdc81795da24aa7443/tools/lldbmacros/core/operating_system.py#L19>
)
*.*

If we do make native plug-in we could do things very similar to the python
> OS plug-in:
> - Define the registers for threads, possibly adding the ability to specify
> more than one register context to allow different threads to have different
> registers. This register context would define which registers are
> available, how they are grouped, etc.
> - For each thread, figure out which register context it will use from one
> of the register layouts that was specified in above step
> - allow read/write access to registers

At the beginning of my work I was thinking about implementing that on
public API level, thus making it usable in Python OS plug-in, but now I see
that it requires huge changes to LLDB, so I am not sure about the
expediency of this.


On Sat, Jul 13, 2019 at 1:01 AM Greg Clayton <clayborg at gmail.com> wrote:

>
>
> On Apr 3, 2019, at 10:05 AM, Alexander Polyakov via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
>
> Hi lldb-dev,
>
> Currently I'm working on an OS plug-in for multiple operating systems and
> architectures, during my work, I noted a few moments I want to discuss with
> the community.
>
> 1) Adding RegisterContext to SB API:
>
>
> Are you asking for the ability to create external native plug-ins instead
> of the python OS plug-in interface?
>
>
>     if you want your OS plug-in to support multiple architectures you need
> to implement
>     things like *get_register_info, get_register_data...* for each
> architecture.
>     In my mind, we could do that using RegisterContext, for example:
>     *get_register_info* could just call
> RegisterContext::GetRegisterContextAtIndex(idx), the number
>     of registers could be obtained from
> RegisterContext::GetRegisterCount();
>
>
> What is missing from the python OS plug-in interface here? A register
> context represents all of the registers so I don't follow what you mean
> with what is stated above about asking for a register context by index. So
> you want multiple architectures to show up in the same process? If so this
> will require many changes to LLDB as each thread currently is assumed to
> have the same architecture as the process.
>
>     *get_register_data *could return SBRegisterContext instead of just
> bytes, then the process of
>     fetching the register values might look as: for each register
>     SBRegisterContext::WriteRegister(reg_info, reg_value).
>     Please correct me if I'm missing something.
>
>
> I know the python OS plug-in doesn't have the ability to write a register
> right now. Again, a RegisterContext is a group of all of the register for a
> thread, so I am not sure SBRegisterContext is the right naming here.
>
> If we do make native plug-in we could do things very similar to the python
> OS plug-in:
> - Define the registers for threads, possibly adding the ability to specify
> more than one register context to allow different threads to have different
> registers. This register context would define which registers are
> available, how they are grouped, etc.
> - For each thread, figure out which register context it will use from one
> of the register layouts that was specified in above step
> - allow read/write access to registers
>
> The python OS plug-in has the ability to define a single different
> register context for threads, and the ability read registers. The
> architecture is assumed to be the same.
>
>
> 2) New lldb-mi command: -info-os
>     the gdb-mi documentation defines this command and there is a problem
> with it. To fully
>     implement it, we should be able to get CPU ID a thread is running on,
> but lldb
>     does not have an abstraction for CPU ID at all, so it becomes unreal
> at least for now.
>     I'm going to partly implement this command for Zephyr (e.g. return
> some value to indicate
>     that the CPU ID is undefined) and I want to know if the community is
> interested in implementing
>     that command inside lldb-mi (at least in part).
>
>
> We could implement the ability for a target to have registers for
> registers that are globally accessible, like the CPU ID register. Any
> register that has a single value for all threads in a  process would fall
> into this category. The discovery and reading and writing would be very
> similar to lldb_private::RegisterContext, just a different set.
>
>
> --
> Alexander
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>

-- 
Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190713/d36564b1/attachment-0001.html>