[lldb-dev] Further Linux adventures

[Joel Dillon]

There was another stray plain int I'd missed in the code that reads
registers, truncating the PC.
The attached patch makes lldb compile (modulo some link ordering dependency
problems that
I don't have enough cmake-fu to fix properly) and work on Linux (and as a
bonus prevents a
segfault when attempting to attach to a running process, though that
functionality appears
to be unimplemented as yet). I also added some extra logging for ptrace
that helped me catch
some of the problems.

On Thu, Oct 27, 2011 at 12:54 PM, Greg Clayton <gclayton at apple.com> wrote:

>
> The darwin ptrace call looks from <sys/ptrace.h> looks like:
>
> int ptrace(int _request, pid_t _pid, caddr_t _addr, int _data);
>
> 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.
>
> 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:
>
> void
> LinuxThread::BreakNotify(const ProcessMessage &message)
> {
>    bool status;
>    LogSP log (ProcessLinuxLog::GetLogIfAllCategoriesSet
> (LINUX_LOG_THREAD));
>
>    assert(GetRegisterContextLinux());
>    status = GetRegisterContextLinux()->UpdateAfterBreakpoint();
>    assert(status && "Breakpoint update failed!");
>
>    // With our register state restored, resolve the breakpoint object
>    // corresponding to our current PC.
>    assert(GetRegisterContext());
>    lldb::addr_t pc = GetRegisterContext()->GetPC();
>    if (log)
>        log->Printf ("LinuxThread::%s () PC=0x%8.8llx", __FUNCTION__, pc);
>    lldb::BreakpointSiteSP
> bp_site(GetProcess().GetBreakpointSiteList().FindByAddress(pc));
>    assert(bp_site);
>    lldb::break_id_t bp_id = bp_site->GetID();
>    assert(bp_site && bp_site->ValidForThisThread(this));
>
>
>    m_breakpoint = bp_site;
>    m_stop_info = StopInfo::CreateStopReasonWithBreakpointSiteID(*this,
> bp_id);
> }
>
>
>
> 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:
>
> (lldb) log enable plugin.process.linux thread
> (lldb) run
>
> 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?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20111030/f8afd5b6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linux.diff
Type: text/x-patch
Size: 7360 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20111030/f8afd5b6/attachment.bin>