> 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
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
