HI,
a couple of random shots in the dark:
- could you paste the output of "frame variable --raw-output s"? (This
disables lldb's type formatters. The goal is to see if the problem is
in the formatter, or in lldb not finding the variable in the first
place).
- could you compile your test executab
It more likely has something to do with LLDB being multi-threaded and
failing to push the process IO handler on stack. It sounds like a bug,
but it's hard to diagnose without more info. Could you try enabling
logging (log enable -f some_file.txt lldb process) and send that over
when this problem hi
Hello,
While compiling with clang for i386, I notice that the CFI
information is distributed between the .eh_frame section and the
.debug_frame section, meaning for some functions the CFI info is present in
the .debug_frame section whereas for some it is present in the .eh_frame.
Now looking
https://llvm.org/bugs/show_bug.cgi?id=25624
Bug ID: 25624
Summary: TestFdLeak fails on FreeBSD with Python 2.7.10
Product: lldb
Version: unspecified
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: normal
https://llvm.org/bugs/show_bug.cgi?id=25625
Bug ID: 25625
Summary: TestCppIncompleteTypes failing on FreeBSD 11 buildbot
Product: lldb
Version: unspecified
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: no
https://llvm.org/bugs/show_bug.cgi?id=25626
Bug ID: 25626
Summary: expectedFailureClang decorator may not work on FreeBSD
Product: lldb
Version: unspecified
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: n
I've been working on an old rev that we'd released on; now I'm much closer
to ToT as we move towards our next major Hexagon release.
Core dumps on the old rev would print out a listing/disassembly for each
thread in the core dump. Now it doesn't.
ToT does this, on x86 Linux:
>bin/lldb ~
lldb should be able to read both. Can you file a bug please?
On Tue, Nov 24, 2015 at 02:50:20PM +0100, Ravitheja Addepally via lldb-dev
wrote:
> Hello,
>While compiling with clang for i386, I notice that the CFI
> information is distributed between the .eh_frame section and the
> .debug_f