https://llvm.org/bugs/show_bug.cgi?id=27719
Bug ID: 27719
Summary: No way to send stdin to remote process from command
line
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
It would be nice to get a patch that gets rid of the Mutex.h/Mutex.cpp and
switches over to using C++11 std::mutex/std::recursive_mutex and get rid of
Condition.h/Condition.cpp for std::condition_variable. Then we can be more
consistent. We need to make sure the C++ standard libraries are ready
I mean std::recursive_mutex is recursive
On Wed, May 11, 2016 at 3:01 PM Zachary Turner wrote:
> Yes, eventually we should move to std::mutex and std::condition_variable,
> in which case it behaves as expected (std::mutex is non recursive,
> std::mutex is recursive).
>
>
>
> On Wed, May 11, 2016
Yes, eventually we should move to std::mutex and std::condition_variable,
in which case it behaves as expected (std::mutex is non recursive,
std::mutex is recursive).
On Wed, May 11, 2016 at 2:20 PM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> From lldb/source/Host/windows/Mute
From lldb/source/Host/windows/Mutex.cpp:
Mutex::Mutex () :
m_mutex()
{
m_mutex = static_cast(malloc(sizeof(CRITICAL_SECTION)));
InitializeCriticalSection(static_cast(m_mutex));
}
//--
// Default constructor.
//
// Cr
Thanks for the explanation and the patch.
I tried it and the exception is gone.
The debug info also seems complete. As complete as can be for an LTO build...
I attached a modified patch with the calls to ExtractDIEsIfNeeded() on separate
threads.
Should I submit it for review ?
-Philippe
https://llvm.org/bugs/show_bug.cgi?id=27710
Omair Javaid changed:
What|Removed |Added
Assignee|lldb-dev@lists.llvm.org |omair.jav...@linaro.org
--
You are receiving th
https://llvm.org/bugs/show_bug.cgi?id=27710
Bug ID: 27710
Summary: Ptrace interface doesnt allow un-aligned watchpoints
on aarch64 linux
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Hi,
thank you for investigating this.
So, what you are describing should normally work. Generally
obj_file->GetDebugSymbolFilePaths() (SymbolVendorELF.cpp:99) should
return the correct name to look for the debug file. E.g., in my case
for libpthread it returns "libpthread-2.19.so", and indeed the
