Community
Participate
Working Groups
http://lldb.llvm.org This debugger seems to be gaining in popularity and platform support (Mac, Linux, FreeBSD). I think it would be nice to support it. It's interesting that it has a C++ interface in a shared library, it could be very fast.
Yes, that would be awesome and fit well now that we have llvm compiler support for builds. And it would finally be a second DSF implementation that we can ensure we're being generic. Be wary of the shared library, though, if there's a crash in it, it takes out the whole IDE. We need to make sure we're protected somehow with crash handlers and such.
Any update on that? With the last update on Mac there is no GDB provided by default. I managed to install it manually but I'd doubt that many users want to go through that process...
Isn't GDB included in the command-line tools? AFAIK, it wasn't there by default before, you had to install Xcode then the command line tools in Preferences. Now you can just install the command-line tools. I have done some experimentation with the LDDB shared library but I haven't gotten really far. But I agree it would be nice to have support for LLDB :) Unfortunately, I think this might be too big of a feature for me to tackle on my free time but I'd be happy to help with smaller bugs and testing.
Unfortunately they seem not to be included in the commandline tools anylonger. We had to install GDB today through mac ports today which for whatever reason failed a few times.
I can confirm that. It's not on my Mac either. gdb must have been part of the OS. Crap...
Unfortunately I have no clue how much effort it is to fix this bug nor where to start. Nevertheless I think this might become a big issue, at the latest with the next release. What are your plans regarding this issue? Is there anything I could help with?
Just to be consistent, looks like gcc is gone with XCode 5. Rather it's there, but it said this when I ran it: dschaefer$ gcc clang: error: no input files LOL. Anyway, support for LLVM and LLDB are a must now to support Macs going forward.
The C++ API looks pretty clean for lldb. Just a matter of how we want to hook it in as I said originally. I'd love to see this happen, just to shake out DSF. We'll need help. First, we'll need to document how one would go about it.
(In reply to Doug Schaefer from comment #7) > Just to be consistent, looks like gcc is gone with XCode 5. Rather it's > there, but it said this when I ran it: > > dschaefer$ gcc > clang: error: no input files > > LOL. Anyway, support for LLVM and LLDB are a must now to support Macs going > forward. I think that was the case with 10.8 already. But they continued to ship gdb. Now XCode uses lldb and they think there is no need to still ship gdb. At least that is what I read. We (the mbeddr project, which now will become an Eclipse project as well, see http://www.eclipse.org/proposals/technology.mbeddr/ and http://mbeddr.com) also have a high interest in DSF as we are using DSF to support debugging. Maybe we can invest some resources to help out here. But I need to clarify this with our customer. In any case, we are by no means experts in CDT's code nor the internals of LLDB. I think what we might be able to provide is help with testing and maybe implementation in small, well defined areas.
Yes, Apple dropped GDB from their latest OS X Mavericks. It was totally unnecessary since in the previous version both GDB and LLDB lived peacefully side by side. The only reason may be to steer developers to use Xcode instead of other IDEs. This small omission robs Eclipse of this important functionality, so PLEASE, HELP! Isn't it ironic that Apple started with "1984" commercial and now increasingly look totalitarian dictating people what they can and cannot use.
There seems to be an ongoing work in the lldb repository that aims to provide the mi interface using the lldb driver. This would solve the missing GDB problem on Mac once it is i working state. I'm not sure about the state of the project, but could not we pool some resources to help it make happen? http://llvm.org/viewvc/llvm-project/lldb/trunk/tools/lldb-mi/
I was able to use LLDB as the debugger by replacing gdb with lldb in the preferences window. I did not test it extensively, but I was able to set break points and step through the code.
I cannot confirm this. After replacing the path to GNU gdb (in my case gdb 7.6 on Mac) with the path to lldb (shipped with XCode on Mac), I get the error message shown below and the debugger startup fails. Could not determine GDB version using command: /Applications/Xcode.app/Contents/Developer/usr/bin/lldb --version Unexpected output format: lldb-320.4.156
(In reply to Domenik Pavletic from comment #13) > I cannot confirm this. > > After replacing the path to GNU gdb (in my case gdb 7.6 on Mac) with the > path to lldb (shipped with XCode on Mac), I get the error message shown > below and the debugger startup fails. > > > Could not determine GDB version using command: > /Applications/Xcode.app/Contents/Developer/usr/bin/lldb --version > Unexpected output format: > > lldb-320.4.156 According to http://codeplay.com/portal/lldb-mi-driver---part-2-setting-up-the-driver you need to use the lldb-mi executable, not the standard lldb executable. This probably means you will need to build LLDB yourself.
(In reply to Bruno Medeiros from comment #14) > > Could not determine GDB version using command: > > /Applications/Xcode.app/Contents/Developer/usr/bin/lldb --version > > Unexpected output format: > > > > lldb-320.4.156 CDT expects a GDB-like version format (with the string "gdb" in it, for example). Also, the version itself is used to know what the debugger (normally gdb) can and cannot do. The simplest thing would be to have lldb output a version that looks like GDBs. > According to > http://codeplay.com/portal/lldb-mi-driver---part-2-setting-up-the-driver you > need to use the lldb-mi executable, not the standard lldb executable. This > probably means you will need to build LLDB yourself. Maybe this lldb-mi does exactly that: spew out a version string that looks like gdb's version string.
(In reply to Marc Khouzam from comment #15) > (In reply to Bruno Medeiros from comment #14) > > > According to > > http://codeplay.com/portal/lldb-mi-driver---part-2-setting-up-the-driver you > > need to use the lldb-mi executable, not the standard lldb executable. This > > probably means you will need to build LLDB yourself. > > Maybe this lldb-mi does exactly that: spew out a version string that looks > like gdb's version string. I doubt it's just that. From what I understand, the whole MI interpreter mode is only included in lldb-mi, not the standard lldb executable. Unfortunately I wasn't able to try it out myself: I tried compiling lldb but it failed with some obscure error. :( (Honestly, I hate compiling C/C++ projects! - it seems like 90% of the time the compilation fails, even if I carefully follow the instructions...)
We need to be able to handle version numbers in different formats. Would be nice to have an extension point where you provide a regex and a handler to figure things out.
I think that LLDB integration should be a very high priority because as of OSX Mavericks, GDB no longer works on OSX, and based on my dealings with the GDB developers, they have no intention of fixing the issues. What I have confirmed is that when debugging any non-trivial program, such as the python interpreter, gdb will hang on OSX with 100% cpu usage. The problem started somewhere after 6.3, as the Apple provided GDB 6.3 works perfectly. I've verified this problem with GDB 7.9 and 7.7. Also verified this on 3 different machines, with 3 different OSX versions. On OSX 10.7, when using the built in GDB 6.3, no problems are found. The initial breakpoint in main is always found just fine, and the first 3-4 breakpoints are also found, then after say 3-4 continues, gdb itself will hang with 100% cpu usage. Because GDB no longer works on OSX, I've had to switch to Xcode for any debugging activities, and it is very annoying to do all the editing in eclipse, then have to switch over to Xcode to debug. What I also can confirm is that debugging with LLDB is orderers of magnitude faster and more stable than with GDB. Also, LLDB provides significantly more information that GDB, and is extremely useful. I unfortunately do not have any time available to contribute to developing the LLDB integration, however I would be very happy to assist in testing, or other tasks that do not require a great deal of time.
Have you tried using lldb-mi instead of gdb from eclipse (mars)? I have with limited success > > I unfortunately do not have any time available to contribute to developing > the LLDB integration, however I would be very happy to assist in testing, or > other tasks that do not require a great deal of time.
I tried all approaches: 1- I use sometimes Xcode. It works fine but is not suited for multi-languages projects nor for sharing project on other platforms like Linux or Windows 2- I used GDB 7.7.1 for a while. It works for simple programs but cannot deal with code in dynamic libraries. 3- I tried LLDB-MI also, and while promising, it seems not to be mature yet. Variables values are not always updated and we get many error messages (gdb command not implemented). What is more irritating is the obligation to run in remote debugging more and start the remote process manually. I decide to create my own MI to LLDB project which can debug a local application or attach to a running application on Mac OS X. It is a light project intended to bridge the gap before LLDB-MI gets more mature or best, Eclipse support LLDB natively. LLDBMI2 is quite complete and I use it now for my own projects. If it can help, the project il located on Github at https://github.com/freedib/lldbmi2. It comes as a CDT Eclipse project and relies on LLDB framework available with Xcode, Command line Tools or built from LLVM source code.
I guess the obvious question is why not contribute to the LLDB/MI project?
(In reply to Didier Bertrand from comment #20) > 1- I use sometimes Xcode. It works fine but is not suited for > multi-languages projects nor for sharing project on other platforms like > Linux or Windows Agreed, Xcode is not ideal, but I have been forced to switch to Xcode because GDB has not worked on OS X since 10.8. The GDB team is also unwilling to fix the OS X issues. The Xcode editor and the whole Xcode environment is horrible compared to eclipse for C++ development. But unfortunately, currently, Xcode is the only IDE on OS X with a working debugger. > 2- I used GDB 7.7.1 for a while. It works for simple programs but cannot > deal with code in dynamic libraries. I don't think GDB can even deal with static libraries any more, I'm not sure if it can't handle PIC code. In any case, when attempting to use GDB in any version newer than I think 6.2 (not sure of the version), it will hang with 100% CPU usage after debugging steps. I guess the question is which LLDB API is Xcode using?
Since I've posted the original message on this thread about GDB / LLDB issue on MacOS X, I've discovered that you can still use GDB in all versions of MacOS, including Yosemite. However, you need to download GDB source code from http://www.gnu.org/software/gdb/download/ Then after building it, you will need to "sign" the application with appropriate certificate, and reboot the system before you can use it. See https://sourceware.org/gdb/wiki/BuildingOnDarwin about how to use 'codesign' and 'task gated' commands. Here are the steps you need to take: 1. download gdb source code 2. become root (su command) 3. build the application using configure, make, and make install commands 4. put the new gdb application to /usr/local/bin 5. vi /System/Library/LaunchDaemons/com.apple.taskgated.plist change option -s to -sp and save the file 6. spctl --master-disable 7. create 'gdb-cert' certificate in System using Keychain Access application 8. codesign -s gdb-cert `which gdb` 9. restart the computer. Now you can use gdb as a standalone debugger or use it in Eclipse.
(In reply to Jim Knarf from comment #23) You right. and GDB works as expected in most cases (at least in my case) if you don't need to debug dynamic libraries. Did you test it with code in dylib? As stated in comment #18 and comment #22, it was not supported in GDB 7.7.1 and releases notes of newer version (7.9.1) doesn’t mention added support for it. Last year, I compared source code from GNU 6,3 and Apple 6.3 and discovered that Apple had added a lot of code to handle dynamic libraries.
(In reply to Doug Schaefer from comment #21) > I guess the obvious question is why not contribute to the LLDB/MI project? Good question. I thought to contribute to LLDB-MI, but 3 things refrained me: - The code complexity. LLDB-MI is a huge program (36000 lines in 160 files) comparing to LLDBMI2 (2000 lines in 12 files). It makes intensive use of classes and a has good separation of input/factory/output, but has complexity which comes with level of abstraction. In comparison, my debugger looks naive: read command from CDT, execute LLDB’s equivalent, send answer to CDT, one command at the time. Not great code, but enough for a gateway. - LLDB-MI uses remote debugging and I would have to rewrite the launching part of the program to use local debugging. - Development cycle and debugging (with GDB lol) is easier and faster with a small application. When LLDB-MI was released last august, I already had a python version of my project. But it was too slow to be really usable. Migration to C code (in C++ envelope) was straight-forward when I (recently) discovered how to use LLDB framework C API. Anyway, My project is still in beta phase. When most bugs will be cleared, I don’t exclude to contribute to LLDB-MI, which is nevertheless more versatile, or contribute to direct support of LLDB in Eclipse.
(In reply to Didier Bertrand from comment #25) > (In reply to Doug Schaefer from comment #21) I wanted to share my comments on Didier's work. I feel that what he is doing seems to be what Eclipse users like me need. I personally don't understand the complexities of LLDB-MI and what it does beyond what Didier wrote. I've also found LLDB-MI is difficult to build requiring one to download a lot of the llvm and clang code along with it. I also don't understand why LLDB-MI requires one to treat it as a remote debugger. It's not a simple drop-in replacment for gdb. Didier's program is extremely simply to build. Even though he provides an Eclipse project for it, you can build it with just one clang invocation that names all the cpp files and links to the LLDB framework. It builds in seconds. I have been testing Didier's program for a day now and have found it to work quite well with the type of debugging I do in Eclipse which is mostly setting breakpoints, reading variables and single-stepping through code. It's new software and it has some kinks, but Didier's been very responsive and is working with me to knock out the bugs. I haven't tested it in a multi-threaded environment so I don't know how it would work there. The software is also simple enough in architecture that other people in the community should be able to extend it further if Didier needs some help. So, this is a big thanks to Didier for a long needed Eclipse to lldb interface.
Xcode 7.3.1 comes with a lldb-mi binary. It would be nice if CDT could work with that.
(In reply to Per Mildner from comment #27) > Xcode 7.3.1 comes with a lldb-mi binary. It would be nice if CDT could work > with that. Did you try it? Replace gdb command line with it in launch configuration
I tried to use but I am giving up on CDT on OS X until I hear that someone gets it working at all. See Bug 493591.
(In reply to Per Mildner from comment #27) > Xcode 7.3.1 comes with a lldb-mi binary. It would be nice if CDT could work > with that. Cool! Thanks for letting us know. Was waiting for this. We do have reports that it works. We'll validate it and hopefully close this one off.
*** Bug 493591 has been marked as a duplicate of this bug. ***
Found it. It's at: /Applications/Xcode.app/Contents/Developer/usr/bin/lldb-mi It doesn't get linked into /usr/bin, probably because it's still in development. Running into the same issues that Per had. I'm getting: Error in final launch sequence Failed to execute MI command: -file-exec-and-symbols Debug/HelloWorld Error message from debugger back end: Command 'file-exec-and-symbols'. Target binary 'Debug/HelloWorld' is invalid. error: unable to find executable for 'Debug/HelloWorld' Command 'file-exec-and-symbols'. Target binary 'Debug/HelloWorld' is invalid. error: unable to find executable for 'Debug/HelloWorld' Now this is using Mac GCC and not clang. But I don't think that should matter since they're the same executable in Xcode.
I can push my WIP integration. There are problems with breakpoints but I can step over simple programs.
Here it is: https://github.com/MarkZ3/Eclipse-CDT-WIP/tree/lldb-mi What it does: - A new launcher delegate that has 'lldb-mi' as the default command - Always launch with target-async on, otherwise it doesn't work - Always pass the absolute path to the binary. Relative to the working dir doesn't seem to work What's missing: - probably a lot! - Breakpoints don't seem to work anymore. But I haven't been able to test with a more recent lldb-mi lately (My Ubuntu actually shuts down completely when I try to compile it from source!). Perhaps a path issue again? - Create a feature, integrate to update site, etc. - Attach to process Feel free to make pull requests :) I think once local debugging works fairly well, it will be OK to put in CDT master.
Quick update: - Fixed bad rebase I did which broke a bunch of stuff (variables not updating, etc) - Fixed a hang in launch sequence - Breakpoints now work. lldb-mi doesn't handle absolute paths in combination with -break-insert so for now, just use the last segment of the path. I'll prepare a patch to fix the real issue in lldb-mi so that there is no work around needed. - Fixed modifying the lldb-mi command path in the debug configuration (OK/Apply buttons were not updating) - On Mac, the default command path is set to /Applications/Xcode.app/Contents/Developer/usr/bin/lldb-mi when it exists. If Xcode is installed after debug configuration, one has to "reset to defaults" to get it detected again (I might improve that if necessary). Next: - Attach mode (local). Once this works, I'll be able to debug lldb with lldb in CDT :) - Memory view. Not sure why it's not working yet!
Awesome. Thanks Marc-Andre!
I'm still working on this on and off. (In reply to Marc-Andre Laperle from comment #35) > Next: > - Attach mode (local). Once this works, I'll be able to debug lldb with lldb > in CDT :) This works now! > - Memory view. Not sure why it's not working yet! Memory view works but you can't change values. Here's the list of issues/things-to-do that I came up with: https://github.com/MarkZ3/Eclipse-CDT-WIP/issues?q=is%3Aopen+is%3Aissue+label%3Alldb-mi This is what I am targeting for CDT 9.1: https://github.com/MarkZ3/Eclipse-CDT-WIP/issues?q=is%3Aopen+is%3Aissue+milestone%3A9.1+label%3Alldb-mi I am planning to push to Gerrit in 3/4 patches this week. (In reply to Marc-Andre Laperle from comment #35) > ... lldb-mi doesn't handle absolute paths in combination > with -break-insert so for now, just use the last segment of the path. I'll > prepare a patch to fix the real issue in lldb-mi so that there is no work > around needed. This was fixed in lldb-mi :) https://reviews.llvm.org/D22902
New Gerrit change created: https://git.eclipse.org/r/78293
New Gerrit change created: https://git.eclipse.org/r/78292
New Gerrit change created: https://git.eclipse.org/r/78294
New Gerrit change created: https://git.eclipse.org/r/78291
Gerrit change https://git.eclipse.org/r/78291 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=5e32334aa01341525ffc24c88cacb23eaf963ba8
Gerrit change https://git.eclipse.org/r/78292 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=b7e23cab72c8c21cb710dec9192148c1aeba8ab5
Gerrit change https://git.eclipse.org/r/78293 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=4548f0a7bc0dcb2dc3ec6ee60ea940b2e7096b30
Gerrit change https://git.eclipse.org/r/78294 was merged to [master]. Commit: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=84a7eefeb29ad96043d78fa48d3268eb8849a840
Sweet! Thanks Marc-Andre!
(In reply to Doug Schaefer from comment #46) > Sweet! Thanks Marc-Andre! :) There are definitely issues left to fix but I'm hoping to fix some more things for 9.1.
