Moving this to the public list because it seems useful to see what other
members of the community have to say as well.
On Mon, Oct 12, 2015 at 4:22 PM Zachary Turner wrote:
> It's worth also pointing out that if we go the route of supporting both
> then everyone running the test suite will need
Please see the llvm-dev thread here and direct all discussion there:
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
I tried to repro it using standard LLDB client on a simple program that I could
share. Well, the problem does not exactly repro as in my case - i.e. the signal
is not re-delivered to the thread. But LLDB does get confused state: the
program continues but at the same time lldb shows its prompt as
There was a bug in how the thread plans that were made for the InferiorCall*
functions in InferiorCallPOSIX.cpp that would cause the thread plan for running
the function to get discarded too early. That was fixed in r250084, you might
also try that out and see if it fixes your issue.
Jim
> On
https://llvm.org/bugs/show_bug.cgi?id=25147
Bug ID: 25147
Summary: remote lldb-XX.expr temporary files when we are
done with them
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Sta
https://llvm.org/bugs/show_bug.cgi?id=25123
lab...@google.com changed:
What|Removed |Added
CC||lab...@google.com
Assignee|lldb-de
On 8 October 2015 at 17:08, Eugene Birukov wrote:
> Yes, that's exactly what I see, thanks a lot!
You're wellcome.
>
> Does it explain why I see SIGILL reappear when I let process continue after
> mmap execution? I.e. do I need to look into this more?
No. That could still be a bug somewhere. Feel
