jingham added a comment. I really don't want to pollute the lldb driver options with gdb equivalents (or really any duplicate spellings of already present functionality). For the lldb command line, I want us to have the freedom to do the best job of making the lldb options consistent and easy to document, understand and use, and adding in random duplicate options from gdb will only make this harder.
If you have simple gdb startup commands then translating them into the lldb way should be straightforward, and the burden of learning how lldb works from the command line for these purposes is just not that great and if you are going to use lldb you should just buck up and browse "lldb --help" a bit... If you have complex gdb command lines, you are going to have to rework them anyway to deal with other differences between lldb and gdb. I don't think mixing the two would add enough value to be worth the uglification. lldb is a different debugger from gdb and I think we should be fine with being that. As to Eric's point, I don't think you would need to do any refactoring of lldb to create a gdb compatible shell on top of lldb. The SB API's were sufficient to do the gdb-mi mode and should be sufficient for a gdb driver as well. If you wanted to reuse the command parser code to make it run in lldb or gdb mode, that would take a bunch of work! But I think you'd be crazy to do it that way. The two command syntaxes are quite different, and I think you'd cause yourself much more trouble trying to jam the two together than you would gain from code sharing... After all, the gdb command language is pretty much unstructured, and the command line is parsed ad hoc by the command that receives it, so implementing the parser part of gdb would be very little work, and you wouldn't be able to reuse the part of lldb that does structured commands since the gdb ones aren't. As you got further along in the project, you'd probably have to add a few more customization points to lldb to implement all the gdb features. For instance you'd probably want to be able to implement stop-hooks in something other than the lldb command line commands. But that's all work that we would want to do in lldb anyway and just haven't gotten around to. But you could probably get a pretty long way just on the current SB API's. Finally, I agree with Raphael about IDE's. There are SB API's to do all the things you can set up with command line options - and if there's anything missing there we can and should add it. So if you want to make an IDE using lldb, you should be using the SB API's. If you are trying to use the same IDE code to drive gdb & lldb you should be using the MI interface, which again can specify everything you need to run a session after you get started so you shouldn't need compatibility with driver options. And if there's spare cycles and desire to support this sort of thing that effort would much better go into supporting the lldb-mi which is currently languishing for lack of maintainers, than in trying to fool an IDE into thinking the lldb and gdb command lines are the same. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61737/new/ https://reviews.llvm.org/D61737 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
