Skip to content
  1. Jul 30, 2013
  3. Jul 29, 2013
    • Ed Maste's avatar
      Use flag instead of rwlock state to track process running state · 64fad60e
      Ed Maste authored 
      LLDB requires that the inferior process be stopped before, and remain
stopped during, certain accesses to process state.

Previously this was achieved with a POSIX rwlock which had a write lock
taken for the duration that the process was running, and released when
the process was stopped.  Any access to process state was performed with
a read lock held.

However, POSIX requires that pthread_rwlock_unlock() be called from the
same thread as pthread_rwlock_wrlock(), and lldb needs to stop and start
the process from different threads.  Violating this constraint is
technically undefined behaviour, although as it happens Linux and Darwin
result in the unlock proceeding in this case.  FreeBSD follows POSIX
more strictly, and the unlock would fail, resulting in a hang later upon
the next attempt to take the lock.

All read lock consumers use ReadTryLock() and handle failure to obtain
the lock (typically by logging an error "process is running").  Thus,
instead of using the lock state itself to track the running state, this
change adds an explicit m_running flag.  ReadTryLock tests the flag, and
if the process is not running it returns with the read lock held.

WriteLock and WriteTryLock are renamed to SetRunning and TrySetRunning,
and (if successful) they set m_running with the lock held.  This way,
read consumers can determine if the process is running and act
appropriately, and write consumers are still held off from starting the
process if read consumers are active.

Note that with this change there are still some curious access patterns,
such as calling WriteUnlock / SetStopped twice in a row, and there's no
protection from multiple threads trying to simultaneously start the
process.  In practice this does not seem to be a problem, and was
exposing other undefined POSIX behaviour prior to this change.

llvm-svn: 187377
      64fad60e
    • Ashok Thirumurthi's avatar
      Adds a DW_OP_call_frame_cfa handler when evaluating DWARF 3/4 expressions · 6e264d39
      Ashok Thirumurthi authored 
      in LLDB that load the canonical frame address rather than a location list.

- Handles the simple case where a CFA can be pulled from the current stack frame.
- Fixes more than one hundred failing tests with gcc 4.8!

TODO: Use UnwindPlan::GetRowForFunctionOffset if the DWARFExpression needs
to be evaluated in a context analogous to a virtual unwind (perhaps using RegisterContextLLDB).

- Also adds some comments to DWARFCallFrameInfo whenever I got confused.

llvm-svn: 187361
      6e264d39
  5. Jul 27, 2013
  7. Jul 26, 2013
  9. Jul 25, 2013
  11. Jul 24, 2013