<div dir="ltr"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span style="color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"></span>Are you asking for the ability to create external native plug-ins instead of the python OS plug-in interface? </span></blockquote><div><span class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">The main idea is to have one common native/Python OS plug-in that can be extended with new architectures and operating systems.</span> <br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"></span><span style="font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)">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.</span></blockquote><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><span style="color:rgb(0,0,0)">The </span><i style="color:rgb(0,0,0)">RegisterContext </i><span style="color:rgb(0,0,0)">already provides register info, so h</span><font color="#000000">aving it in a public API makes it possible to get rid of duplicating register info definitions (</font><a href="https://github.com/apple/darwin-xnu/blob/a449c6a3b8014d9406c2ddbdc81795da24aa7443/tools/lldbmacros/core/operating_system.py#L19" style="color:rgb(0,0,0)">example</a><font color="#000000">)</font><i style="color:rgb(0,0,0)">.<br></i><div style="font-family:Arial,Helvetica,sans-serif"><br class="gmail-Apple-interchange-newline"><blockquote style="color:rgb(34,34,34);margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">If we do make native plug-in we could do things very similar to the python OS plug-in:<br>- 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.<br>- For each thread, figure out which register context it will use from one of the register layouts that was specified in above step<br>- allow read/write access to registers </blockquote><div style=""><font color="#000000">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.</font></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jul 13, 2019 at 1:01 AM Greg Clayton <<a href="mailto:clayborg@gmail.com">clayborg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Apr 3, 2019, at 10:05 AM, Alexander Polyakov via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:</div><br class="gmail-m_-6734562579167019826Apple-interchange-newline"><div><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Hi lldb-dev,<br><br>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.<br><br>1) Adding RegisterContext to SB API:<br></div></div></div></div></blockquote><div><br></div><div>Are you asking for the ability to create external native plug-ins instead of the python OS plug-in interface? </div><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"></div></div></blockquote></div><br><blockquote type="cite"><div><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">    if you want your OS plug-in to support multiple architectures you need to implement</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">    things like <b>get_register_info, get_register_data...</b> for each architecture.<br>    In my mind, we could do that using RegisterContext, for example: <br>    <b>get_register_info</b> could just call RegisterContext::GetRegisterContextAtIndex(idx), the number <br>    of registers could be obtained from RegisterContext::GetRegisterCount();<br></div></div></div></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">    <b>get_register_data </b>could return SBRegisterContext instead of just bytes, then the process of</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">    fetching the register values might look as: for each register <br>    SBRegisterContext::WriteRegister(reg_info, reg_value).<br>    Please correct me if I'm missing something.<br></div></div></div></div></blockquote><div><br></div>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. </div><div><br></div><div>If we do make native plug-in we could do things very similar to the python OS plug-in:</div><div>- 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.</div><div>- For each thread, figure out which register context it will use from one of the register layouts that was specified in above step</div><div>- allow read/write access to registers</div><div><br></div><div>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. </div><div><div><br></div></div><div><blockquote type="cite"><div><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br>2) New lldb-mi command: -info-os<br>    the gdb-mi documentation defines this command and there is a problem with it. To fully<br>    implement it, we should be able to get CPU ID a thread is running on, but lldb<br>    does not have an abstraction for CPU ID at all, so it becomes unreal at least for now.<br>    I'm going to partly implement this command for Zephyr (e.g. return some value to indicate <br>    that the CPU ID is undefined) and I want to know if the community is interested in implementing<br>    that command inside lldb-mi (at least in part).</div></div></div></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div><div dir="ltr"><div dir="ltr"><div><br></div>-- <br><div dir="ltr" class="gmail-m_-6734562579167019826m_5204971009704125322gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="font-family:arial,helvetica,sans-serif;font-size:12.8px">Alexander</span><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
_______________________________________________<br>lldb-dev mailing list<br><a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br></div></blockquote></div><br></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:12.8px">Alexander</span><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>