<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">If the LinuxPlugin is always debugging a native local process, the GetByteOrder() should look like:<div><br></div><div><div>ByteOrder</div><div>ProcessLinux::GetByteOrder() const</div><div>{</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>lldb::endian::InlHostByteOrder();</div><div>}</div><div><br></div><div>I don't think, someone correct me if I am wrong, that the ProcessLinux plug-in can be used for remote debugging? If so, the above fix will work. Else, checking with the object file is ok as long as you always have the correct file selected prior to running. </div><div><br></div><div>For the ptrace logging instead of using sprintf, I would suggest using the StringStream:</div><div><br></div><div>#include "lldb/Core/StreamString.h"<br><br></div><div>StringStream strm;</div><div><br></div><div>Then your display_bytes() function would take a "lldb_private::Stream &" instead of a "char *" and your code would look like:</div><div><br></div><div><br></div><div><div>void </div><div>display_bytes (lldb_private::StreamString &strm, void *bytes, uint32_t count)</div><div>{</div><div> uint8_t *ptr = (uint8_t *)bytes;</div><div> const uint32_t loop_count = std::min<uint32_t>(DEBUG_PTRACE_MAXBYTES, count);</div><div> for(uint32_t i=0; i<loop_count; i++)</div><div> {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>strm.Printf ("[%x]", *ptr);</div><div> ptr++;</div><div> }</div><div>}</div></div><div><br></div><div>Also, don't worry about #ifdef'ing out the ptrace logging, there is already a "ptrace" logging channel that you are using, If you only want to see the logging when "verbose" is enabled which can be done via:</div><div><br></div><div><div> LogSP log (ProcessLinuxLog::GetLogIfAllCategoriesSet (LINUX_LOG_PTRACE));</div></div><div><div><div> LogSP verbose_log (ProcessLinuxLog::GetLogIfAllCategoriesSet (LINUX_LOG_PTRACE | LINUX_LOG_VERBOSE));</div></div></div><div><br></div><div>Then just check for the "verbose_log" when you want to dump the bits. So instead of:</div><div><br></div><div><br></div><div><div>#ifdef DEBUG_PTRACE</div><div> if (log)</div><div> {</div></div><div><br></div><div><br></div><div>You would have:</div><div><br></div><div> if (verbose_log)</div><div> {</div><div><br></div><div><br></div><div>So I would switch over to using the StreamString and don't use the #ifdef DEBUG_PTRACE. One goal in LLDB is to always be able to log the things that are going wrong, and the ptrace calls and the data fall into those categories.</div><div><br></div><div>Greg Clayton</div><div><br></div><div><div>On Oct 30, 2011, at 1:07 PM, Joel Dillon wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">There was another stray plain int I'd missed in the code that reads registers, truncating the PC.<br>The attached patch makes lldb compile (modulo some link ordering dependency problems that<br>I don't have enough cmake-fu to fix properly) and work on Linux (and as a bonus prevents a <br>
segfault when attempting to attach to a running process, though that functionality appears<br>to be unimplemented as yet). I also added some extra logging for ptrace that helped me catch<br>some of the problems.<br><br><div class="gmail_quote">
On Thu, Oct 27, 2011 at 12:54 PM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com">gclayton@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
The darwin ptrace call looks from <sys/ptrace.h> looks like:<br>
<br>
int ptrace(int _request, pid_t _pid, caddr_t _addr, int _data);<br>
<br>
I never try to use "int" "long" as types when programming in LLDB and we would try to exclusively use "uint*_t" and "int*_t" where the type is explicit. The only exception to the rule is if you are wrapping an API (like say "ptrace") where it returns a specific type in the header file ("int" in our header file). If the return types differ from system to system, we should templatize the code the uses it.<br>
<br>
So overall we should try to use the explicitly sized integer typedefs from stdint.h (uint8_t, uint16_t, uint32_t, etc) to avoid any such issues. It sounds like there are some issues in the Linux plug-in. The function is:<br>
<br>
void<br>
LinuxThread::BreakNotify(const ProcessMessage &message)<br>
{<br>
bool status;<br>
LogSP log (ProcessLinuxLog::GetLogIfAllCategoriesSet (LINUX_LOG_THREAD));<br>
<br>
assert(GetRegisterContextLinux());<br>
status = GetRegisterContextLinux()->UpdateAfterBreakpoint();<br>
assert(status && "Breakpoint update failed!");<br>
<br>
// With our register state restored, resolve the breakpoint object<br>
// corresponding to our current PC.<br>
assert(GetRegisterContext());<br>
lldb::addr_t pc = GetRegisterContext()->GetPC();<br>
if (log)<br>
log->Printf ("LinuxThread::%s () PC=0x%8.8llx", __FUNCTION__, pc);<br>
lldb::BreakpointSiteSP bp_site(GetProcess().GetBreakpointSiteList().FindByAddress(pc));<br>
assert(bp_site);<br>
lldb::break_id_t bp_id = bp_site->GetID();<br>
assert(bp_site && bp_site->ValidForThisThread(this));<br>
<br>
<br>
m_breakpoint = bp_site;<br>
m_stop_info = StopInfo::CreateStopReasonWithBreakpointSiteID(*this, bp_id);<br>
}<br>
<br>
<br>
<br>
Liiks like the PC is read from the register context and there doesn't seem to be a breakpoint site. Enable the logging before you run:<br>
<br>
(lldb) log enable plugin.process.linux thread<br>
(lldb) run<br>
<br>
This should cause the PC to be logged. Then you should check that a software breakpoint was indeed set at this location. You might also want to verify that no one removed the breakpoint site after stopping?<br>
<br>
<br>
</blockquote></div><br>
<span><linux.diff></span></blockquote></div><br></div></body></html>