[lldb-dev] LLDB 4.0.0 crashes on Windows 7
Hi, I installed a 32-bit Windows build of LLVM 4.0.0 from this page: http://llvm.org/builds/ where it is identified as "based on SVN r284979 (24 October 2016)". (I actually wanted only LLDB, but there doesn't seem to be a separate installer for that.) The machine where I installed it runs the 64-bit Windows 7 OS. The only setting I changed during the installation was the installation directory: instead of the default under "C:\Program Files (x86)" I've installed it under d:\usr. The installation went fine. After installing, I found that I needed Python 3.5.x, so I installed this: https://www.python.org/ftp/python/3.5.2/python-3.5.2.exe The installed Python works correctly. After all this, lldb crashes when it attempts to start a debuggee. Specifically, whenever I say "process launch -s" inside the debugger, it crashes. (The information about the crash available in the Windows Event Viewer is at the end of this message.) The same happens if I type "lldb PROGRAM" from the Windows cmd.exe prompt. Until I try to launch the debuggee, lldb works: I can type the various commands, including "help" and they produce expected results. The crash is inside liblldb.dll, and the exception code seems to indicate that some C runtime library function is called with incorrect or invalid arguments. Other programs that came with the installation -- clang, llvm-ar, llvm-objdump -- seem to work fine and produce the expected results. In particular, I compiled a small C program with clang. So the installation seems to work fine, and only lldb crashes. What am I doing wrong? Thanks in advance for any help. Here's the info from the Event Viewer: Log Name: Application Source:Application Error Date: 13/11/2016 13:24:58 Event ID: 1000 Task Category: (100) Level: Error Keywords: Classic User: N/A Computer: C1050100036.ness.com Description: Faulting application name: lldb.exe, version: 4.0.0.0, time stamp: 0x580fd053 Faulting module name: liblldb.dll, version: 4.0.0.0, time stamp: 0x580fd046 Exception code: 0xc417 Fault offset: 0x027295d2 Faulting process id: 0x1564 Faulting application start time: 0x01d23da09025cbd5 Faulting application path: D:\usr\LLVM\bin\lldb.exe Faulting module path: D:\usr\LLVM\bin\liblldb.dll Report Id: cef982bb-a993-11e6-a608-001b10002aec Event Xml: http://schemas.microsoft.com/win/2004/08/events/event";> 1000 2 100 0x80 121846 Application C1050100036.ness.com lldb.exe 4.0.0.0 580fd053 liblldb.dll 4.0.0.0 580fd046 c417 027295d2 1564 01d23da09025cbd5 D:\usr\LLVM\bin\lldb.exe D:\usr\LLVM\bin\liblldb.dll cef982bb-a993-11e6-a608-001b10002aec ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB 4.0.0 crashes on Windows 7
> From: Rudy Pons > Date: Tue, 15 Nov 2016 01:08:52 +0100 > Cc: lldb-dev@lists.llvm.org > > I had a similar crash, and submitted a patch commited in rL285843 > You could try to build afte this version from source, or wait for an updated > build. Thanks, I will have to wait, as I don't have MSVC installed (and don't plan to). ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB 4.0.0 crashes on Windows 7
> Date: Tue, 15 Nov 2016 18:08:03 +0200 > Cc: lldb-dev@lists.llvm.org > From: Eli Zaretskii via lldb-dev > > > From: Rudy Pons > > Date: Tue, 15 Nov 2016 01:08:52 +0100 > > Cc: lldb-dev@lists.llvm.org > > > > I had a similar crash, and submitted a patch commited in rL285843 > > You could try to build afte this version from source, or wait for an > > updated build. > > Thanks, I will have to wait, as I don't have MSVC installed (and don't > plan to). My wait is over, I installed the latest snapshot today. I'm glad to report that now I can debug programs, although the simple invocation of the debugger, as in lldb some.exe or lldb -f some.exe still crashes. I need to invoke lldb without any arguments, then load the program with "file some.exe", and finally run it with "process launch". Then it works. Is this expected? There's also a strange problem with error messages: I don't see them until I quit the debugger. For example, if I say "file foo.exe" where foo.exe doesn't exist, I get the prompt back with no error message, and without the usual announcement that foo.exe will be debugged. Only after I type "quit" to exit the debugger, I see the error message about foo.exe being non-existent. Am I doing something wrong? Thanks. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLDB 4.0.0 crashes on Windows 7
> From: Zachary Turner > Date: Tue, 06 Dec 2016 16:22:51 + > > I have never seen either of those problems, but I can test it out and see if > I can reproduce. Thanks. If you are unable to reproduce, I wonder why it happens to me. The system where I installed lldb is just a vanilla Windows 7 box. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Using LLDB API on windows
> Date: Tue, 04 Apr 2017 03:00:21 + > From: Zachary Turner via lldb-dev > > As the person who added most of the support for debugging Windows > executables, I can tell you that I never > tested a MinGW executable (nor was it one of my original goals). It doesn't > entirely surprise me that things are > behaving this way, but I'm not sure what the exact cause would be off the top > of my head. MinGW executables > and msvc Win32 executables use an entirely different ABI, so I would exepct > the non lldb-server path to be a > little wonky since I always assumed MSVC ABI in my implementation. Are you sure you are talking about MinGW and not Cygwin or MSYS? Because MinGW executables are native Win32 programs, so much so that you can load MSVC DLLs from a MinGW program and vice versa. Or maybe I don't understand what you mean by "ABI". I did try debugging MinGW-compiled executables with lldb, and it did work for me, FWIW. Apologies if by "MinGW" this thread means MSYS/MSYS2. MSYS is a fork of Cygwin, and yes, it uses a different ABI, which attempts to emulate a Posix system on top of Windows. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Using LLDB API on windows
> From: Russell Greene > Date: Tue, 04 Apr 2017 14:50:23 + > Cc: ted.woodw...@codeaurora.org, lldb-dev@lists.llvm.org > > Well I would guess the main problem is lldb being compiled in a msys > environment which I guess lldb > recognizes to be so posix to try and launch lldb-server. The results I gave > you are from the > mingw-w64-x86_64-lldb package in msys2. That's a native 64-bit build of lldb, AFAIU. It should be okay for debugging native Windows programs, at least the 64-bit programs. (I only ever used a 32-bit build of lldb for debugging 32-bit MinGW programs, and it worked OK.) > Pretty sure mingw and msvc have different ABIs though (at least for C++) they > have completely different > name mangling algos. Yes, but that's not necessarily relevant for debugging, except that you might see mangled names. ___ 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
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
Re: [lldb-dev] Emacs LLDB support & the GDB/MI Interface
> From: "Ted Woodward" > Cc: > Date: Mon, 31 Jul 2017 13:24:31 -0500 > > The best thing to do is give us a list of commands that are failing, in a bug > opened in Bugzilla at http://bugs.llvm.org . The URL I provided (after several mistaken attempts ;-) included a lits of the failing commands. ___ 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
> From: Ilia K > Date: Sun, 6 Aug 2017 13:20:13 +0300 > Cc: Ted Woodward , yllumin...@gmail.com, > jan.kratoch...@redhat.com, LLDB > > You are probably got it but yes, -file-list-exec-source-files and -break-list > commands are not implemented yet. > I'll try to find the time to fix it. Thanks. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] lldb-mi doesn't work on MS-Windows
Since at least two snapshots ago, lldb-mi no longer works on MS-Windows: D:\usr\archive>lldb-mi d:\usr\bin\emacs.exe MI: Error: Driver. LLDB Debugger. MI: Error: Driver Manager. Driver 'Machine Interface Driver Version: 1.0.0.9' (ID:'MIDriver') initialise failed. Driver. LLDB Debugger. It actually reacts the same to any invocation, even if you only want it to display the usage: D:\usr\LLVM\bin>lldb-mi --help MI: Error: Driver. LLDB Debugger. MI: Error: Driver Manager. Driver 'Machine Interface Driver Version: 1.0.0.9' (ID:'MIDriver') initialise failed. Driver. LLDB Debugger. What am I doing wrong? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] lldb-mi doesn't work on MS-Windows
> From: Ilia K > Date: Thu, 17 Aug 2017 14:59:01 +0300 > Cc: LLDB > > Did you build it from sources? If yes, please provide your configure options. No, I installed the snapshot available from https://llvm.org/builds/. (I used the 32-bit binaries from there.) ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
