> > 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 <clayb...@gmail.com> wrote: > > > On Apr 3, 2019, at 10:05 AM, Alexander Polyakov via lldb-dev < > lldb-dev@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@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > -- Alexander
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
