Re: [lldb-dev] Custom expression evaluation target options
Hi On 03/12/15 18:02, Greg Clayton wrote: Each expression has a language so we should be able to get the Language* for renderscript: lldb_private::Language* language = lldb_private::Language::FindPlugin (m_expr.GetLanguage()); Then you can add a new virtual class on lldb_private::Language that can get any additional compiler flags needed for expressions and just make it work? The renderscript language would set the appropriate ABI flags needed? Thanks very much for clarifying my suspicion. I was working on a very similar implementation to this, but your way is cleaner, so I'll go ahead and prepare a patch. All the Best Luke ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 25742] New: Use After Free Vulnerability lldb_private::Debugger
https://llvm.org/bugs/show_bug.cgi?id=25742 Bug ID: 25742 Summary: Use After Free Vulnerability lldb_private::Debugger Product: lldb Version: 3.4 Hardware: Macintosh OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: ichai...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified Created attachment 15398 --> https://llvm.org/bugs/attachment.cgi?id=15398&action=edit Proof-of-Concept for the crash A use after free vulnerability exists in com.apple.LLDB.framework on Apple Mac OS X 10.11.1 in LLDB version 340.4.110.1, that on exploitation, would allow an attacker to execute arbitrary code with the privileges of the user. Steps to reproduce: ~/D/A/t/lldbPython ❯❯❯ lldb (lldb)script Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D. >>> import lldb >>> s=lldb.SBDebugger.Create() >>> s.__swig_destroy__(s) >>> print s Backtrace of the crash: 0 com.apple.LLDB.framework 0x000105c0ae0a lldb::SBDebugger::GetDescription(lldb::SBStream&) + 28 1 com.apple.LLDB.framework 0x000105c5be4c _wrap_SBDebugger___str__(_object*, _object*) + 128 2 org.python.python 0x000108ea0a0b PyEval_EvalFrameEx + 13400 3 org.python.python 0x000108e9d3c1 PyEval_EvalCodeEx + 1583 4 org.python.python 0x000108e422e5 0x108e1a000 + 164581 5 org.python.python 0x000108e24202 PyObject_Call + 99 6 org.python.python 0x000108e2eff5 0x108e1a000 + 86005 7 org.python.python 0x000108e24202 PyObject_Call + 99 8 org.python.python 0x000108ea2e83 PyEval_CallObjectWithKeywords + 165 9 org.python.python 0x000108e6aa8f 0x108e1a000 + 330383 10 org.python.python 0x000108e53e17 _PyObject_Str + 127 11 org.python.python 0x000108e53eb0 PyObject_Str + 12 12 org.python.python 0x000108e53b70 0x108e1a000 + 236400 13 org.python.python 0x000108e3afb3 PyFile_WriteObject + 338 14 org.python.python 0x000108e9fb01 PyEval_EvalFrameEx + 9550 15 org.python.python 0x000108e9d3c1 PyEval_EvalCodeEx + 1583 16 org.python.python 0x000108ea143e PyEval_EvalFrameEx + 16011 17 org.python.python 0x000108e9d3c1 PyEval_EvalCodeEx + 1583 18 org.python.python 0x000108ea34ae 0x108e1a000 + 562350 19 org.python.python 0x000108ea030c PyEval_EvalFrameEx + 11609 20 org.python.python 0x000108e9d3c1 PyEval_EvalCodeEx + 1583 21 org.python.python 0x000108ea34ae 0x108e1a000 + 562350 22 org.python.python 0x000108ea030c PyEval_EvalFrameEx + 11609 23 org.python.python 0x000108ea3541 0x108e1a000 + 562497 24 org.python.python 0x000108ea030c PyEval_EvalFrameEx + 11609 25 org.python.python 0x000108e9d3c1 PyEval_EvalCodeEx + 1583 26 org.python.python 0x000108ea34ae 0x108e1a000 + 562350 27 org.python.python 0x000108ea030c PyEval_EvalFrameEx + 11609 28 org.python.python 0x000108e9d3c1 PyEval_EvalCodeEx + 1583 29 org.python.python 0x000108ea34ae 0x108e1a000 + 562350 30 org.python.python 0x000108ea030c PyEval_EvalFrameEx + 11609 31 org.python.python 0x000108ea3541 0x108e1a000 + 562497 32 org.python.python 0x000108ea030c PyEval_EvalFrameEx + 11609 33 org.python.python 0x000108e9d3c1 PyEval_EvalCodeEx + 1583 34 org.python.python 0x000108e9cd8c PyEval_EvalCode + 54 35 org.python.python 0x000108ebca42 0x108e1a000 + 666178 36 org.python.python 0x000108ebcbff PyRun_StringFlags + 109 37 org.python.python 0x000108ebcb53 PyRun_SimpleStringFlags + 69 38 com.apple.LLDB.framework 0x0001079e1cef IOHandlerPythonInterpreter::Run() + 245 39 com.apple.LLDB.framework 0x0001078e7b43 lldb_private::Debugger::ExecuteIOHandlers() + 63 40 com.apple.LLDB.framework 0x0001079c89cc lldb_private::CommandInterpreter::RunCommandInterpreter(bool, bool, lldb_private::CommandInterpreterRunOptions&) + 126 41 com.apple.LLDB.framework 0x000105c0ca80 lldb::SBDebugger::RunCommandInterpreter(bool, bool) + 68 42 lldb 0x000105bdc05f Driver::MainLoop() + 2347 43 lldb 0x000105bdc594 main + 268 44 libdyld.dylib 0x7fff9654e5ad start + 1 Please find the Proof-of-Concept attached as
[lldb-dev] [Bug 25743] New: TestModulesInlineFunctions.py test_expr() failing on Darwin
https://llvm.org/bugs/show_bug.cgi?id=25743 Bug ID: 25743 Summary: TestModulesInlineFunctions.py test_expr() failing on Darwin Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified Looks like we're failing to find the module. Xcode 7.2 Beta 4, OS X 10.11.1 (15B42), El Capitan. runCmd: settings set target.clang-module-search-paths "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lang/objc/modules-inline-functions" output: runCmd: expr @import myModule; 3 runCmd failed! error: Header search couldn't locate module myModule error: 1 errors parsing expression FAIL Traceback (most recent call last): File "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 550, in wrapper return func(self, *args, **kwargs) File "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2288, in dsym_test_method return attrvalue(self) File "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lang/objc/modules-inline-functions/TestModulesInlineFunctions.py", line 51, in test_expr substrs = ["int", "3"]) File "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2769, in expect self.runCmd(str, msg=msg, trace = (True if trace else False), check = not error, inHistory=inHistory) File "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2695, in runCmd msg if msg else CMD_MSG(cmd)) AssertionError: False is not True : Variable(s) displayed correctly Config=x86_64-clang Session info generated @ Fri Dec 4 10:02:44 2015 To rerun this test, issue the following command from the 'test' directory: ./dotest.py -A x86_64 -C clang -v -t -f ModulesInlineFunctionsTestCase.test_expr_dsym -- 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
Re: [lldb-dev] LLDB using Valgrind's embedded gdbserver
The issue is LLDB wants to know information in the registers in the register
context regarding how they map to "generic" registers. For x86_64 this means:
LLDB_REGNUM_GENERIC_PC -> rip
LLDB_REGNUM_GENERIC_SP -> rsp
LLDB_REGNUM_GENERIC_FP -> rbp
LLDB_REGNUM_GENERIC_RA ->
LLDB_REGNUM_GENERIC_FLAGS -> rflags
LLDB_REGNUM_GENERIC_ARG1-> rdi
LLDB_REGNUM_GENERIC_ARG2-> rsi
LLDB_REGNUM_GENERIC_ARG3-> rdx
LLDB_REGNUM_GENERIC_ARG4-> rcx
LLDB_REGNUM_GENERIC_ARG5-> r8
LLDB_REGNUM_GENERIC_ARG6-> r9
We also want to know what DWARF register number each register has, what
compiler register number (for EH frame) each register is, and more.
There are two ways to do this:
1 - if you want to change the LLDB code
2 - if you want to make this work by only modifying valgrind's GDB server
If you go with option 1, it looks like the bug here is in:
static void
AugmentRegisterInfoViaABI (RegisterInfo ®_info, ConstString reg_name, ABISP
abi_sp)
It grabs the register info from the ABI and fills it in, but it wasn't filling
in the generic register number. I just fixed this with:
r254743 | gclayton | 2015-12-04 10:37:48 -0800 (Fri, 04 Dec 2015) | 1 line
Fill in the generic register kind if in AugmentRegisterInfoViaABI if it is
available.
So if you update your sources, it might start working.
If you don't want the change LLDB, you can make the XML returned for the
registers contain extra attributes to specify these things. If you check the
code in ProcessGDBRemote.cpp around line 4327:
bool
ParseRegisters (XMLNode feature_node, GdbServerTargetInfo &target_info,
GDBRemoteDynamicRegisterInfo &dyn_reg_info, ABISP abi_sp)
You can see the extra attributes a "reg" element node can contain.
We extended the XML to include keys that LLDB can use. The assert that is
causing the crash is the fact that we are asking a register context for the
"generic" register that is "arg1". If you can modify the XML that is returned
to mark up the registers so the generic name is attached to each register, it
will help out LLDB. "debugserver" actually used this modified XML, so to see
what it would look like with all of the new things we added you can copy what
you need from the XML below. But lets look at the definition for "rip" alone:
Note we specify regnum (the lldb register number), offset (the byte offset for
this register in the register context), altname, group_id (the register group
this should appear in, see the "groups" at the end of the XML to see the
register set names), gcc_regnum which is the compiler register number,
dwarf_regnum, and the generic register name ("pc", "sp", "fp", "arg1", "arg2",
etc).
So our full XML which specifies the compiler register numbers, DWARF register
numbers and generic register names looks like:
l
So if you get the generic register numbers fixed, you should probably not be
crashing anymore.
Greg Clayton
> On Dec 3, 2015, at 4:24 PM, Daniel Trebbien via lldb-dev
> wrote:
>
> Hello,
>
> I am working on enhancing Valgrind's embedded gdbserver to allow LLDB to use
> it (https://bugs.kde.org/show_bug.cgi?id=356174 ). After adding support for
> 'qC' packets to the embedded gdbserver, LLDB is able to continue the halted
> program running under Valgrind; however, a short moment later LLDB crashes.
>
> I am using OS X 10.11.1 (15B42) and lldb-340.4.110.1.
>
> The location of the segmentation fault is
> ABISysV_x86_64::GetArgumentValues(lldb_private::Thread&,
> lldb_private::ValueList&) const + 147:
>
> [ 0] 0x00010432d7ad
> LLDB`ABISysV_x86_64::GetArgumentValues(lldb_private::Thread&,
> lldb_private::ValueList&) const + 147 at ABISysV_x86_64.cpp:485:32
>481addr_t current_stack_argument = sp + 8; // jump over return
> address
>482
>483uint32_t argument_register_ids[6];
>484
> -> 485argument_register_ids[0] = reg_ctx->GetRegisterInfo
> (eRegisterKindGeneric, LLDB_REGNUM_GENERIC_ARG1)->kinds[eRegisterKindLLDB];
>
>
> Someone at Apple Developer Relations (ADR) informed me that unlike gdb, lldb
> does not have an initial target definition set, and relies on the gdbserver
> to tell it which registers the gdbserver supports. This can be done either
> by responding to 'qRegisterInfo XX' packets or to
> 'qXfer:features:read:target.xml'.
>
> ADR also informed me about the
> plugin.process.gdb-remote.target-definition-file LLDB setting and the example
> target definitions at
> http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/
> I can confirm that using either x86_64_linux_target_definition.py or
> x86_64_target_definition.py fixes the segfault issue.
>
> Valgrind's gdbserver does not support qRe
[lldb-dev] Windows Buildbot binaries
Hello, I have been investigating using the LLDB-MI tool for debugging a project at work on Windows, but have been unable to work out how to build the program from source (I spent several days with errors I couldn't work out how to fix before giving up). Would it be possible to download the binaries that the Windows buildbot generates? It would save me a large amount of hassle. Thanks Nick ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Fwd: lldb doesn't work on centos7
Also I found that the size of my program binary increases from 140M to 180M
after -fno-limit-debug-info is added. Seems a lot of debug info is added?
2015-11-25 10:24 GMT+08:00 陶征霖 :
> Hi Pavel,
>
> Thanks for your reply. Seems lldb not finding the variable in the first
> place.
>
> * thread #1: tid = 154, 0x00400e5e a.out`main + 94 at t.cpp:5,
> name = 'a.out', stop reason = breakpoint 1.1
> frame #0: 0x00400e5e a.out`main + 94 at t.cpp:5
>2 using namespace std;
>3 int main() {
>4 string s = "aa";
> -> 5 cout << s;
>6 }
> (lldb) frame variable --raw-output s
> (std::__1::string) s = {}
>
> I added -fno-limit-debug-info in my test, and it works now. But why?
>
> Thanks,
> Zhenglin
>
>
>
> 2015-11-24 19:21 GMT+08:00 Pavel Labath :
>
>> 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] Fwd: lldb doesn't work on centos7
Hi Pavel,
Thanks for your reply. Seems lldb not finding the variable in the first
place.
* thread #1: tid = 154, 0x00400e5e a.out`main + 94 at t.cpp:5, name
= 'a.out', stop reason = breakpoint 1.1
frame #0: 0x00400e5e a.out`main + 94 at t.cpp:5
2 using namespace std;
3 int main() {
4 string s = "aa";
-> 5 cout << s;
6 }
(lldb) frame variable --raw-output s
(std::__1::string) s = {}
I added -fno-limit-debug-info in my test, and it works now. But why?
Thanks,
Zhenglin
2015-11-24 19:21 GMT+08:00 Pavel Labath :
> 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] lldb doesn't work on centos7
Yes the debug info does get bigger. But this is better than having the compiler
omit the "std::string" definition so that you can't view stuff from the STL.
Greg
> On Nov 24, 2015, at 7:22 PM, 陶征霖 via lldb-dev wrote:
>
> Also I found that the size of my program binary increases from 140M to 180M
> after -fno-limit-debug-info is added. Seems a lot of debug info is added?
>
> 2015-11-25 10:24 GMT+08:00 陶征霖 :
> Hi Pavel,
>
> Thanks for your reply. Seems lldb not finding the variable in the first place.
>
> * thread #1: tid = 154, 0x00400e5e a.out`main + 94 at t.cpp:5, name =
> 'a.out', stop reason = breakpoint 1.1
> frame #0: 0x00400e5e a.out`main + 94 at t.cpp:5
>2 using namespace std;
>3 int main() {
>4 string s = "aa";
> -> 5 cout << s;
>6 }
> (lldb) frame variable --raw-output s
> (std::__1::string) s = {}
>
> I added -fno-limit-debug-info in my test, and it works now. But why?
>
> Thanks,
> Zhenglin
>
>
>
> 2015-11-24 19:21 GMT+08:00 Pavel Labath :
> 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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Windows Buildbot binaries
We don't have anything set up like this at the moment unfortunately. It could happen in the future, but we've been spending our limited amount of Windows resources making new debugging scenarios work, and just haven't gotten to this. I'd be happy to help diagnose build errors if you're willing to give it a go again. The biggest difficulty is the Python part. If you don't care about contributing patches to LLDB or scripting LLDB, and you just want to use it for something, you can set LLDB_DISABLE_PYTHON=1 on the command line and that should fix most of the difficulty that goes with building LLDB. I've been working on getting Python 3 support working, which should also greatly simplify the build process, but it's not quite there yet, although it's very close. On Fri, Dec 4, 2015 at 11:11 AM Ridgway, Nick via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hello, > > > > I have been investigating using the LLDB-MI tool for debugging a project > at work on Windows, but have been unable to work out how to build the > program from source (I spent several days with errors I couldn’t work out > how to fix before giving up). Would it be possible to download the > binaries that the Windows buildbot generates? It would save me a large > amount of hassle. > > > > > > Thanks > > Nick > ___ > 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] [Bug 25744] New: Linux build breaks when both python 2 and python 3 are installed
https://llvm.org/bugs/show_bug.cgi?id=25744 Bug ID: 25744 Summary: Linux build breaks when both python 2 and python 3 are installed Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified I'm not sure if this is new, but when both Python 2 and 3 are installed on Linux, the readline overload module has code that is not Python-3 compatible. (I'm pretty sure I've run python 2/3 systems in the past and not hit this, so it might have crept in more recently). I think we want to limit Linux to Python 2.x in the short term. Later, we can iron out the Python 3 bits. An alternative would be to fix up the basic wrapper code to work on both Python 2 and 3, but that's a bit more involved. I prefer to handle that as a lower priority follow up step. See initial report here: https://bugs.swift.org/browse/SR-14 I'm still working on getting the exact repro environment, but calling it out now. -- 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
Re: [lldb-dev] New test summary results formatter
One thing I excluded from the newer test results detail info is the architecture. I personally haven't ever needed that. I'd be happy to leave that out until we find someone who really needs it, just to keep it shorter. On Thu, Dec 3, 2015 at 5:14 PM, Todd Fiala wrote: > That seems reasonable. I'll work that in. > > -Todd > > On Dec 3, 2015, at 4:55 PM, Zachary Turner wrote: > > It would also be nice if the summary statistics were printed after the > list of failing / errored tests. The reason is that it involves a fixed > number of lines to print the table, but the list of failures and errors is > a variable number of lines which could potentially be very long and push > the statistics off the screen. > > On Thu, Dec 3, 2015 at 10:08 AM Zachary Turner wrote: > >> Ahh I read further and see this was already mentioned by Pavel. >> >> On Thu, Dec 3, 2015 at 10:06 AM Zachary Turner >> wrote: >> >>> On Wed, Dec 2, 2015 at 10:20 PM Todd Fiala wrote: >>> On Wed, Dec 2, 2015 at 9:48 PM, Zachary Turner wrote: > > > On Wed, Dec 2, 2015 at 9:44 PM Todd Fiala > wrote: > >> >> >>> and the classname could be dropped (there's only one class per file >>> anyway, so the classname is just wasted space) >>> >> >> Part of the reason I included that is I've hit several times where >> copy and paste errors lead to the same class name, method name or even >> file >> name being used for a test. I think, though, that most of those are >> addressed by having the path (relative is fine) to the python test file. >> I >> think we can probably get by with classname.methodname (relative test >> path). (From your other email, I think you nuke the classname and keep >> the >> module name, but I'd probably do the reverse, keeping the class name and >> getting rid of the module name since it can be derived from the >> filename). >> > I don't think the filename can be the same anymore, as things will > break if two filenames are the same. > Maybe, but that wasn't my experience as of fairly recently. When tracking failures sometime within the last month, I tracked something down in a downstream branch with two same-named files that (with the legacy output) made it hard to track down what was actually failing given the limited info of the legacy test summary output. Maybe that has changed since then, but I'm not aware of anything that would have prohibited that. >>> Well I only said "things" will break, not everything will break. Most >>> likely you just didn't notice the problem or it didn't present itself in >>> your scenario. There are definitely bugs surrounding multiple files with >>> the same name, because of some places where we use a dictionary keyed on >>> filename. >>> >>> -- -Todd ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
