tatyana-krasnukha added a comment.
In https://reviews.llvm.org/D39967#1015860, @clayborg wrote:
> So one issue with this is some things, like GDB servers, might not need you
> to disable breakpoints in a range because they actually set the breakpoint
> for you and you don't know what opcode they used. I am hoping this works with
> that and doesn't cause us to manually write to memory when we don't need to
> by forcing every process subclass to always to the manual re-writing of the
> breakpoint opcodes.
It seems I had to use Disable|EnableBreakpointSite instead of
Disable|EnableSoftwareBreakpoint...
================
Comment at: include/lldb/Breakpoint/BreakpointSiteList.h:159-175
+ class Guard final {
+ std::recursive_mutex *m_mutex;
- typedef void (*BreakpointSiteSPMapFunc)(lldb::BreakpointSiteSP &bp,
- void *baton);
+ public:
+ explicit Guard(std::recursive_mutex &mutex) : m_mutex(&mutex) {
+ m_mutex->lock();
+ }
----------------
labath wrote:
> How is this class different from a std::unique_lock ?
std::unique_lock allows to call lock() and unlock() manually. Such flexibility
makes code more bug-prone, so I try to avoid it if it is not really needed.
I might inherit Guard from std::unique_lock and hide these functions, if it
looks better...
https://reviews.llvm.org/D39967
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
