Re: [lldb-dev] Fwd: lldb doesn't work on centos7
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 executable with -fno-limit-debug-info
and see if that helps?
pl
On 23 November 2015 at 02:15, 陶征霖 via lldb-dev wrote:
>
> -- Forwarded message --
> From: 陶征霖
> Date: 2015-11-20 23:10 GMT+08:00
> Subject: lldb doesn't work on centos7
> To: llvm-...@lists.llvm.org
>
>
> Hi,
>
> I build llvm+clang+lldb 3.7.0 from source code on centos7, the build command
> is "cmake -DCMAKE_BUILD_TYPE=Release
> -DCMAKE_INSTALL_PREFIX=${INSTALL_PREFIX} -DLLVM_LIBDIR_SUFFIX=64", there is
> no error during building process.
>
> And then I compile following c++ code using command "clang++ -std=c++11
> -stdlib=libc++ -lc++abi -g t.cpp":
> // t.cpp
> #include
> using namespace std;
> int main() {
>string s = "aa";
>cout << s;
> }
> Try lldb to debug a.out, found that I can't print string s which shows
> empty:
> lldb a.out
> (lldb) target create "a.out"
> Current executable set to 'a.out' (x86_64).
> (lldb) l
>4int main() {
>5 string s = "aa";
>6 cout << s;
>7}
> (lldb) b 6
> Breakpoint 1: where = a.out`main + 94 at t.cpp:6, address =
> 0x00400e5e
> (lldb) r
> Process 150 launched: '/root/a.out' (x86_64)
> Process 150 stopped
> * thread #1: tid = 150, 0x00400e5e a.out`main + 94 at t.cpp:6, name
> = 'a.out', stop reason = breakpoint 1.1
> frame #0: 0x00400e5e a.out`main + 94 at t.cpp:6
>3using namespace std;
>4int main() {
>5 string s = "aa";
> -> 6 cout << s;
>7}
> (lldb) p s
> (std::__1::string) $0 = {}
>
> Could you please help point out what's wrong in my env? Thanks.
>
> Thanks,
> Zhenglin
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] --no-stdin mode kicks in without warning (?)
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 hits. Maybe we can dig something up from that. cheers, pl On 24 November 2015 at 00:08, Ramkumar Ramachandra via lldb-dev wrote: > Hi, > > I never do --no-stdin, because the program I'm debugging often takes > input. If I debug in one of the normal sessions for an extended period > of time, 'continue' returns the (lldb) prompt immediately, which > claims that the program is running (it's actually waiting for input). > At this point, I have no choice but to start over, because there's no > way to go from the --no-stdin mode to the normal mode (?). > > I'm not able to give reproduction steps, but I think it has to do with > the program being multi-threaded? > > Ram > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Inquiry about .debug_frame
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 at the lldb code, I see that this information is only read from the .eh_frame section and not from the .debug_frame section. My questions are the following -> 1) Is there something that I missing ? is the information that I provided in this email correct ? 2) If it is correct, is this expected behavior ? I mean if the CFI info is present in the .debug_frame then I think it should be read ? coz it maybe useful in unwinding scenarios ? BR, A Ravi ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 25624] New: TestFdLeak fails on FreeBSD with Python 2.7.10
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 Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: ema...@freebsd.org CC: llvm-b...@lists.llvm.org Classification: Unclassified On both my (not yet connected) FreeBSD 11 buildbot and local FreeBSD 10 builds: == FAIL: test_fd_leak_basic_dwarf (TestFdLeak.AvoidsFdLeakTestCase) -- Traceback (most recent call last): File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 564, in wrapper return func(self, *args, **kwargs) File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2297, in dwarf_test_method return attrvalue(self) File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 636, in wrapper func(*args, **kwargs) File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1216, in wrapper func(*args, **kwargs) File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py", line 29, in test_fd_leak_basic self.do_test([]) File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/avoids-fd-leak/TestFdLeak.py", line 51, in do_test "Process returned non-zero status. Were incorrect file descriptors passed?") AssertionError: False is not True : Process returned non-zero status. Were incorrect file descriptors passed? Config=x86_64-/usr/bin/cc -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 25625] New: TestCppIncompleteTypes failing on FreeBSD 11 buildbot
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: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: ema...@freebsd.org CC: llvm-b...@lists.llvm.org Classification: Unclassified On my FreeBSD 11 buildbot (not yet added to the build master): == FAIL: test_limit_debug_info_dwarf (TestCppIncompleteTypes.TestCppIncompleteTypes) -- Traceback (most recent call last): File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 564, in wrapper return func(self, *args, **kwargs) File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2297, in dwarf_test_method return attrvalue(self) File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1164, in wrapper func(*args, **kwargs) File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lang/cpp/incomplete-types/TestCppIncompleteTypes.py", line 16, in test_limit_debug_info self.assertFalse(value_f.GetError().Success(), "'expr f' results in an error, but LLDB does not crash") AssertionError: True is not False : 'expr f' results in an error, but LLDB does not crash Config=x86_64-/usr/bin/cc == FAIL: test_limit_debug_info_dwo (TestCppIncompleteTypes.TestCppIncompleteTypes) -- Traceback (most recent call last): File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 578, in wrapper return func(self, *args, **kwargs) File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2306, in dwo_test_method return attrvalue(self) File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1164, in wrapper func(*args, **kwargs) File "/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lang/cpp/incomplete-types/TestCppIncompleteTypes.py", line 16, in test_limit_debug_info self.assertFalse(value_f.GetError().Success(), "'expr f' results in an error, but LLDB does not crash") AssertionError: True is not False : 'expr f' results in an error, but LLDB does not crash Config=x86_64-/usr/bin/cc -- Ran 6 tests in 1.539s -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 25626] New: expectedFailureClang decorator may not work on FreeBSD
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: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: ema...@freebsd.org
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
packages/Python/lldbsuite/test/lang/c/typedef/Testtypedef.py has
@dwarf_test
@expectedFailureClang("llvm.org/pr19238")
def test_with_dwarf(self):
but it reports failure on the in-progress FreeBSD 11 buildbot:
==
FAIL: test_with_dwarf_dwarf (Testtypedef.TypedefTestCase)
Test 'image lookup -t a' and check for correct display at different scopes.
--
Traceback (most recent call last):
File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 564, in wrapper
return func(self, *args, **kwargs)
File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2297, in dwarf_test_method
return attrvalue(self)
File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 564, in wrapper
return func(self, *args, **kwargs)
File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 636, in wrapper
func(*args, **kwargs)
File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lang/c/typedef/Testtypedef.py",
line 29, in test_with_dwarf
self.image_lookup_for_multiple_typedefs()
File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lang/c/typedef/Testtypedef.py",
line 47, in image_lookup_for_multiple_typedefs
substrs = ['name = "' + t + '"'])
File
"/usr/home/user/llvm/tools/lldb/packages/Python/lldbsuite/test/lldbtest.py",
line 2833, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : Data type(s) displayed correctly
(Speculation -- perhaps because our clang is /usr/bin/cc?)
--
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Linux core dump doesn't show listing when loaded
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_test/coredump/lincrash -c ~/lldb_test/coredump/lincore (lldb) target create "/usr2/tedwood/lldb_test/coredump/lincrash" --core "/usr2/tedwood/lldb_test/coredump/lincore" Core file '/usr2/tedwood/lldb_test/coredump/lincore' (x86_64) was loaded. (lldb) thread list Process 0 stopped * thread #1: tid = 0, 0x00401190 lincrash`main + 16 at lincrash.c:5, name = 'lincrash', stop reason = signal SIGSEGV (lldb) I can see the listing by going up and down the stack, but I'd like to see the listing on load. Is the no listing intended? Ted -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Inquiry about .debug_frame
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_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 at the lldb code, I see that this information is only read > from the .eh_frame section and not from the .debug_frame section. My > questions are the following -> > 1) Is there something that I missing ? is the information that I provided > in this email correct ? > 2) If it is correct, is this expected behavior ? I mean if the CFI info is > present in the .debug_frame then I think it should be read ? coz it maybe > useful in unwinding scenarios ? > > > BR, > A Ravi > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
