Re: [lldb-dev] [cfe-dev] [5.0.0 Release] Release Candidate 1 tagged
On 27 Jul 2017, at 00:41, Hans Wennborg via cfe-dev wrote: > > 5.0.0-rc1 has just been tagged. > > Please build, test and upload binaries to the sftp. Let me know if > there are any issues. Built and tested rc1. Test failures on amd64-freebsd10: FAIL: LLVM-Unit :: ExecutionEngine/Orc/./OrcJITTests/DummyRPC.TestClearHandlers (1346 of 38616) FAIL: AddressSanitizer-Unit :: ./Asan-i386-inline-Test/AddressSanitizer.DoubleFreeTest (2480 of 38616) FAIL: AddressSanitizer-Unit :: ./Asan-i386-inline-Test/AddressSanitizer.ReallocFreedPointerTest (2505 of 38616) FAIL: AddressSanitizer-Unit :: ./Asan-i386-inline-Test/AddressSanitizer.UseThenFreeThenUseTest (2542 of 38616) FAIL: AddressSanitizer-Unit :: ./Asan-i386-inline-Test/AddressSanitizer.WrongFreeTest (2546 of 38616) FAIL: AddressSanitizer-Unit :: ./Asan-i386-with-calls-Test/AddressSanitizer.DoubleFreeTest (2589 of 38616) FAIL: AddressSanitizer-Unit :: ./Asan-i386-with-calls-Test/AddressSanitizer.ReallocFreedPointerTest (2615 of 38616) FAIL: AddressSanitizer-Unit :: ./Asan-i386-with-calls-Test/AddressSanitizer.UseThenFreeThenUseTest (2651 of 38616) FAIL: AddressSanitizer-Unit :: ./Asan-i386-with-calls-Test/AddressSanitizer.WrongFreeTest (2655 of 38616) FAIL: AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test/AddressSanitizer.DoubleFreeTest (2698 of 38616) FAIL: AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test/AddressSanitizer.ReallocFreedPointerTest (2723 of 38616) FAIL: AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test/AddressSanitizer.UseThenFreeThenUseTest (2762 of 38616) FAIL: AddressSanitizer-Unit :: ./Asan-x86_64-inline-Test/AddressSanitizer.WrongFreeTest (2765 of 38616) FAIL: AddressSanitizer-Unit :: ./Asan-x86_64-with-calls-Test/AddressSanitizer.DoubleFreeTest (2808 of 38616) FAIL: AddressSanitizer-Unit :: ./Asan-x86_64-with-calls-Test/AddressSanitizer.ReallocFreedPointerTest (2833 of 38616) FAIL: AddressSanitizer-Unit :: ./Asan-x86_64-with-calls-Test/AddressSanitizer.UseThenFreeThenUseTest (2870 of 38616) FAIL: AddressSanitizer-Unit :: ./Asan-x86_64-with-calls-Test/AddressSanitizer.WrongFreeTest (2875 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/asan-sigbus.cpp (2998 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/asan-symbolize-sanity-test.cc (3000 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/closed-fds.cc (3001 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/deep_thread_stack.cc (3005 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/fread_fwrite.cc (3007 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/interception-in-shared-lib-test.cc (3019 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/shared-lib-test.cc (3029 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/stack-use-after-return.cc (3030 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/strndup_oob_test.cc (3035 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/wait.cc (3037 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/wait3.cc (3038 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/wait4.cc (3040 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/Posix/waitid.cc (3139 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/alloca_big_alignment.cc (3140 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/alloca_detect_custom_size_.cc (3142 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/alloca_overflow_partial.cc (3144 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/alloca_overflow_right.cc (3146 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/alloca_underflow_left.cc (3148 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/debug_double_free.cc (3163 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/debug_stacks.cc (3167 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/debug_report.cc (3168 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/deep_stack_uaf.cc (3170 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/describe_address.cc (3172 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/double-free.cc (3173 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/frexp_interceptor.cc (3178 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/global-overflow.cc (3180 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/heap-overflow.cc (3184 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/heavy_uar_test.cc (3185 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/initialization-bug.cc (3188 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/invalid-free.cc (3195 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/invalid-pointer-pairs.cc (3197 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/large_func_test.cc (3198 of 38616) FAIL: AddressSanitizer-i386-freebsd :: TestCases/null_dere
[lldb-dev] Emacs LLDB support & the GDB/MI Interface
Developers here may or may not be aware that there's some serious interest from Emacs users to have proper support for LLDB in Emacs. There's been some pretty heated debate that included RMS, but the community has pretty much told him what they think about his opinion and are willing to accept any solid effort at adding support. The issue has been brought up again here: https://www.reddit.com/r/emacs/comments/6qbwjl/seriously_how_can_i_use_lldb_in_emacs/ And one thread seems to indicate that if if we could "convince LLDB developers to provide a decent implementation of the GDB/MI protocol, then using LLDB from Emacs will be a no-brainer, and probably won't require any sanction from any Emacs developer." Can we get some love from the LLDB dev community to get this moving in the right direction? Unfortunately there are plenty of us macOS developers who use Emacs and really just can't function well without LLDB support. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Emacs LLDB support & the GDB/MI Interface
On Sat, 29 Jul 2017 21:59:03 +0200, ylluminate via lldb-dev wrote: > And one thread seems to indicate that if if we could "convince LLDB > developers to provide > a decent implementation of the GDB/MI protocol, That is an oxymoron. MI protocol was designed to minimize the amount of data transferred between gdb/lldb and a front end. But this communication isn't anything expensive as the debugger always runs on the same host as the frontend anyway (gdb/lldb<->gdbserver link is for remote debugging). Unfortunately complexity of the GDB/MI protocol from this misoptimization leads to many bugs on both sides of the implementation, for GDB: https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&component=mi&list_id=37310&product=gdb&query_format=advanced 101 bugs found. The MI protocol in use does not conform to its spec as there is a bug-to-bug compatibility instead such as: https://sourceware.org/ml/gdb-patches/2008-11/msg00275.html There still also isn't any reasonable MI library to be used by a front end. I find the LLDB API to be a better choice to be used by the frontend/emacs (I have only little but great experience with the LLDB API). Jan ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Emacs LLDB support & the GDB/MI Interface
> Date: Sat, 29 Jul 2017 22:43:59 +0200 > Cc: lldb-dev@lists.llvm.org > From: Jan Kratochvil via lldb-dev > > MI protocol was designed to minimize the amount of data transferred between > gdb/lldb and a front end. But this communication isn't anything expensive as > the debugger always runs on the same host as the frontend anyway > (gdb/lldb<->gdbserver link is for remote debugging). Unfortunately complexity > of the GDB/MI protocol from this misoptimization leads to many bugs on both > sides of the implementation, for GDB: > > https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&component=mi&list_id=37310&product=gdb&query_format=advanced > 101 bugs found. > > The MI protocol in use does not conform to its spec as there is a bug-to-bug > compatibility instead such as: > https://sourceware.org/ml/gdb-patches/2008-11/msg00275.html > > There still also isn't any reasonable MI library to be used by a front end. Correct or not, buggy or not, the Emacs support for GDB is based on MI, and it works reasonably well for the last few years. So much so that Emacs developers have deprecated the previous GUD interface based on annotations (which are also deprecated by the GDB team). > I find the LLDB API to be a better choice to be used by the frontend/emacs > (I have only little but great experience with the LLDB API). Good luck with that attitude having LLDB support in Emacs any time soon. Even supporting it via the ancient GUD, which required a couple of minor changes, was met with some resistance. (Some think that this resistance was overcome, but IMO the jury is still out on that one, and we won't know the truth until an attempt to add that support is made in earnest.) Having LLDB support MI would solve this problem cleanly and seamlessly. It's your call to decide whether Emacs support is important enough to you to do that. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Emacs LLDB support & the GDB/MI Interface
Are we talking about some kind of mi support other than lldb's existing MI interface? Afaik it works reasonably well (for some definition of reasonably well), and is even used for example in msvc on windows to support remote debugging of non windows targets. That said, most lldb developers are paid by their company to work on specific things that are important to their company's users, and emacs support is probably not going to be that high up on the list. So if you can figure out where the deficiencies are in the existing mi implementation, patches are always welcome On Sat, Jul 29, 2017 at 7:39 PM Eli Zaretskii via lldb-dev < lldb-dev@lists.llvm.org> wrote: > > Date: Sat, 29 Jul 2017 22:43:59 +0200 > > Cc: lldb-dev@lists.llvm.org > > From: Jan Kratochvil via lldb-dev > > > > MI protocol was designed to minimize the amount of data transferred > between > > gdb/lldb and a front end. But this communication isn't anything > expensive as > > the debugger always runs on the same host as the frontend anyway > > (gdb/lldb<->gdbserver link is for remote debugging). Unfortunately > complexity > > of the GDB/MI protocol from this misoptimization leads to many bugs on > both > > sides of the implementation, for GDB: > > > https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&component=mi&list_id=37310&product=gdb&query_format=advanced > > 101 bugs found. > > > > The MI protocol in use does not conform to its spec as there is a > bug-to-bug > > compatibility instead such as: > > https://sourceware.org/ml/gdb-patches/2008-11/msg00275.html > > > > There still also isn't any reasonable MI library to be used by a front > end. > > Correct or not, buggy or not, the Emacs support for GDB is based on > MI, and it works reasonably well for the last few years. So much so > that Emacs developers have deprecated the previous GUD interface based > on annotations (which are also deprecated by the GDB team). > > > I find the LLDB API to be a better choice to be used by the > frontend/emacs > > (I have only little but great experience with the LLDB API). > > Good luck with that attitude having LLDB support in Emacs any time > soon. Even supporting it via the ancient GUD, which required a couple > of minor changes, was met with some resistance. (Some think that this > resistance was overcome, but IMO the jury is still out on that one, > and we won't know the truth until an attempt to add that support is > made in earnest.) > > Having LLDB support MI would solve this problem cleanly and > seamlessly. It's your call to decide whether Emacs support is > important enough to you to do that. > ___ > 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] Emacs LLDB support & the GDB/MI Interface
On July 30, 2017 6:30:04 AM GMT+03:00, Zachary Turner wrote: > Are we talking about some kind of mi support other than lldb's > existing MI > interface? Afaik it works reasonably well (for some definition of > reasonably well), and is even used for example in msvc on windows to > support remote debugging of non windows targets. > > That said, most lldb developers are paid by their company to work on > specific things that are important to their company's users, and emacs > support is probably not going to be that high up on the list. > > So if you can figure out where the deficiencies are in the existing mi > implementation, patches are always welcome > On Sat, Jul 29, 2017 at 7:39 PM Eli Zaretskii via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Date: Sat, 29 Jul 2017 22:43:59 +0200 > > > Cc: lldb-dev@lists.llvm.org > > > From: Jan Kratochvil via lldb-dev > > > > > > MI protocol was designed to minimize the amount of data > transferred > > between > > > gdb/lldb and a front end. But this communication isn't anything > > expensive as > > > the debugger always runs on the same host as the frontend anyway > > > (gdb/lldb<->gdbserver link is for remote debugging). > Unfortunately > > complexity > > > of the GDB/MI protocol from this misoptimization leads to many > bugs on > > both > > > sides of the implementation, for GDB: > > > > > > https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&component=mi&list_id=37310&product=gdb&query_format=advanced > > > 101 bugs found. > > > > > > The MI protocol in use does not conform to its spec as there is a > > bug-to-bug > > > compatibility instead such as: > > > https://sourceware.org/ml/gdb-patches/2008-11/msg00275.html > > > > > > There still also isn't any reasonable MI library to be used by a > front > > end. > > > > Correct or not, buggy or not, the Emacs support for GDB is based on > > MI, and it works reasonably well for the last few years. So much so > > that Emacs developers have deprecated the previous GUD interface > based > > on annotations (which are also deprecated by the GDB team). > > > > > I find the LLDB API to be a better choice to be used by the > > frontend/emacs > > > (I have only little but great experience with the LLDB API). > > > > Good luck with that attitude having LLDB support in Emacs any time > > soon. Even supporting it via the ancient GUD, which required a > couple > > of minor changes, was met with some resistance. (Some think that > this > > resistance was overcome, but IMO the jury is still out on that one, > > and we won't know the truth until an attempt to add that support is > > made in earnest.) > > > > Having LLDB support MI would solve this problem cleanly and > > seamlessly. It's your call to decide whether Emacs support is > > important enough to you to do that. > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > Last time I tried, it wasn't "reasonable" enough to start debugging a program under Emacs. See this discussion for details: http://lists.llvm.org/pipermail/llvm-dev/2016-December/108512.html The failed commands it shows are the initial ones issued by Emacs when a debugging session starts. Without support of these commands in lldb-mi there's no hope for any practical debugging using lldb. If llvm developers could implement those minimal commands, maybe the rest would be easier. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Emacs LLDB support & the GDB/MI Interface
On July 30, 2017 7:05:52 AM GMT+03:00, Eli Zaretskii via lldb-dev wrote: > On July 30, 2017 6:30:04 AM GMT+03:00, Zachary Turner > wrote: > > Are we talking about some kind of mi support other than lldb's > > existing MI > > interface? Afaik it works reasonably well (for some definition of > > reasonably well), and is even used for example in msvc on windows to > > support remote debugging of non windows targets. > > > > That said, most lldb developers are paid by their company to work on > > specific things that are important to their company's users, and > emacs > > support is probably not going to be that high up on the list. > > > > So if you can figure out where the deficiencies are in the existing > mi > > implementation, patches are always welcome > > On Sat, Jul 29, 2017 at 7:39 PM Eli Zaretskii via lldb-dev < > > lldb-dev@lists.llvm.org> wrote: > > > > > > Date: Sat, 29 Jul 2017 22:43:59 +0200 > > > > Cc: lldb-dev@lists.llvm.org > > > > From: Jan Kratochvil via lldb-dev > > > > > > > > MI protocol was designed to minimize the amount of data > > transferred > > > between > > > > gdb/lldb and a front end. But this communication isn't anything > > > expensive as > > > > the debugger always runs on the same host as the frontend anyway > > > > (gdb/lldb<->gdbserver link is for remote debugging). > > Unfortunately > > > complexity > > > > of the GDB/MI protocol from this misoptimization leads to many > > bugs on > > > both > > > > sides of the implementation, for GDB: > > > > > > > > > > https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&component=mi&list_id=37310&product=gdb&query_format=advanced > > > > 101 bugs found. > > > > > > > > The MI protocol in use does not conform to its spec as there is > a > > > bug-to-bug > > > > compatibility instead such as: > > > > > https://sourceware.org/ml/gdb-patches/2008-11/msg00275.html > > > > > > > > There still also isn't any reasonable MI library to be used by a > > front > > > end. > > > > > > Correct or not, buggy or not, the Emacs support for GDB is based > on > > > MI, and it works reasonably well for the last few years. So much > so > > > that Emacs developers have deprecated the previous GUD interface > > based > > > on annotations (which are also deprecated by the GDB team). > > > > > > > I find the LLDB API to be a better choice to be used by the > > > frontend/emacs > > > > (I have only little but great experience with the LLDB API). > > > > > > Good luck with that attitude having LLDB support in Emacs any time > > > soon. Even supporting it via the ancient GUD, which required a > > couple > > > of minor changes, was met with some resistance. (Some think that > > this > > > resistance was overcome, but IMO the jury is still out on that > one, > > > and we won't know the truth until an attempt to add that support > is > > > made in earnest.) > > > > > > Having LLDB support MI would solve this problem cleanly and > > > seamlessly. It's your call to decide whether Emacs support is > > > important enough to you to do that. > > > ___ > > > lldb-dev mailing list > > > lldb-dev@lists.llvm.org > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > > > Last time I tried, it wasn't "reasonable" enough to start debugging a > program under Emacs. See this discussion for details: > > http://lists.llvm.org/pipermail/llvm-dev/2016-December/108512.html > > The failed commands it shows are the initial ones issued by Emacs > when a debugging session starts. Without support of these commands in > lldb-mi there's no hope for any > practical debugging using lldb. > If llvm developers could implement those minimal commands, maybe the > rest would be easier. > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev Sorry, I meant http://lists.llvm.org/pipermail/lldb-dev/2016-December/108511.html ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Emacs LLDB support & the GDB/MI Interface
On July 30, 2017 7:15:29 AM GMT+03:00, Eli Zaretskii via lldb-dev wrote: > On July 30, 2017 7:05:52 AM GMT+03:00, Eli Zaretskii via lldb-dev > wrote: > > On July 30, 2017 6:30:04 AM GMT+03:00, Zachary Turner > > wrote: > > > Are we talking about some kind of mi support other than lldb's > > > existing MI > > > interface? Afaik it works reasonably well (for some definition of > > > reasonably well), and is even used for example in msvc on windows > to > > > support remote debugging of non windows targets. > > > > > > That said, most lldb developers are paid by their company to work > on > > > specific things that are important to their company's users, and > > emacs > > > support is probably not going to be that high up on the list. > > > > > > So if you can figure out where the deficiencies are in the > existing > > mi > > > implementation, patches are always welcome > > > On Sat, Jul 29, 2017 at 7:39 PM Eli Zaretskii via lldb-dev < > > > lldb-dev@lists.llvm.org> wrote: > > > > > > > > Date: Sat, 29 Jul 2017 22:43:59 +0200 > > > > > Cc: lldb-dev@lists.llvm.org > > > > > From: Jan Kratochvil via lldb-dev > > > > > > > > > > MI protocol was designed to minimize the amount of data > > > transferred > > > > between > > > > > gdb/lldb and a front end. But this communication isn't > anything > > > > expensive as > > > > > the debugger always runs on the same host as the frontend > anyway > > > > > (gdb/lldb<->gdbserver link is for remote debugging). > > > Unfortunately > > > > complexity > > > > > of the GDB/MI protocol from this misoptimization leads to many > > > bugs on > > > > both > > > > > sides of the implementation, for GDB: > > > > > > > > > > > > > > > https://sourceware.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&component=mi&list_id=37310&product=gdb&query_format=advanced > > > > > 101 bugs found. > > > > > > > > > > The MI protocol in use does not conform to its spec as there > is > > a > > > > bug-to-bug > > > > > compatibility instead such as: > > > > > > > https://sourceware.org/ml/gdb-patches/2008-11/msg00275.html > > > > > > > > > > There still also isn't any reasonable MI library to be used by > a > > > front > > > > end. > > > > > > > > Correct or not, buggy or not, the Emacs support for GDB is based > > on > > > > MI, and it works reasonably well for the last few years. So > much > > so > > > > that Emacs developers have deprecated the previous GUD interface > > > based > > > > on annotations (which are also deprecated by the GDB team). > > > > > > > > > I find the LLDB API to be a better choice to be used by the > > > > frontend/emacs > > > > > (I have only little but great experience with the LLDB API). > > > > > > > > Good luck with that attitude having LLDB support in Emacs any > time > > > > soon. Even supporting it via the ancient GUD, which required a > > > couple > > > > of minor changes, was met with some resistance. (Some think > that > > > this > > > > resistance was overcome, but IMO the jury is still out on that > > one, > > > > and we won't know the truth until an attempt to add that support > > is > > > > made in earnest.) > > > > > > > > Having LLDB support MI would solve this problem cleanly and > > > > seamlessly. It's your call to decide whether Emacs support is > > > > important enough to you to do that. > > > > ___ > > > > lldb-dev mailing list > > > > lldb-dev@lists.llvm.org > > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > > > > > > Last time I tried, it wasn't "reasonable" enough to start debugging > a > > program under Emacs. See this discussion for details: > > > > http://lists.llvm.org/pipermail/llvm-dev/2016-December/108512.html > > > > The failed commands it shows are the initial ones issued by Emacs > > when a debugging session starts. Without support of these commands > in > > lldb-mi there's no hope for any > > practical debugging using lldb. > > If llvm developers could implement those minimal commands, maybe the > > rest would be easier. > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > Sorry, I meant > http://lists.llvm.org/pipermail/lldb-dev/2016-December/108511.html > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev It's embarrassing... The correct URL is http://lists.llvm.org/pipermail/llvm-dev/2016-December/108511.html ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
