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>