From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nicholas Allegra Newsgroups: gmane.emacs.devel Subject: Re: Contributing LLVM.org patches to gud.el Date: Wed, 11 Feb 2015 02:44:42 -0500 Message-ID: References: <87mw4rxkzv.fsf@fencepost.gnu.org> <87y4oavxcy.fsf@fencepost.gnu.org> <87d25juy8m.fsf@fencepost.gnu.org> <83iofa8lu2.fsf@gnu.org> <87wq3qrvjz.fsf@fencepost.gnu.org> <83386d92ox.fsf@gnu.org> <874mqtsoqy.fsf@fencepost.gnu.org> <87mw4lnked.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1423640726 2942 80.91.229.3 (11 Feb 2015 07:45:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Feb 2015 07:45:26 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 11 08:45:26 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YLRzC-0003vF-3X for ged-emacs-devel@m.gmane.org; Wed, 11 Feb 2015 08:45:26 +0100 Original-Received: from localhost ([::1]:43541 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLRz9-0005Wf-TQ for ged-emacs-devel@m.gmane.org; Wed, 11 Feb 2015 02:45:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59630) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLRyx-0005Wa-HZ for emacs-devel@gnu.org; Wed, 11 Feb 2015 02:45:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLRyw-0007Gr-9L for emacs-devel@gnu.org; Wed, 11 Feb 2015 02:45:11 -0500 Original-Received: from mail-we0-x232.google.com ([2a00:1450:400c:c03::232]:57296) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLRyw-0007GY-2Q for emacs-devel@gnu.org; Wed, 11 Feb 2015 02:45:10 -0500 Original-Received: by mail-we0-f178.google.com with SMTP id w62so1604482wes.9 for ; Tue, 10 Feb 2015 23:45:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=y9kZU4zzz7EaumnQoNDNvZADhHFTka3cUwUQZFJPKII=; b=IMNtNQaWsroKCgsKZiRG/OgsZWszSRVroX87K9QQ2JsHKVR8zzcfKq40ehp43blmo7 X148XL95PIglqjbwuBTSSLiprc7piwLIGD+D82NzrIFJwsO0Yv+Ez845W74ovJGtHdnM bjlXM19Q239INoAnXnxl8GBKZK+HgC0mpwi3hSfp4YrlUIZ8MKHt/wB5nPDGBtxOGOmg kU5bskrmsWYNx8FrjhwquXkPXJKC6q7Z1by1bMMu/XJLGj3GqZs6NMw5i/Gfy53MAxAZ WrorHnXfFqvMkjF4d++mYV+THR8P+EpdDEgLqN9u+GavmoGxl/hEKa8dhyUMkf1fu9Dw nFiQ== X-Received: by 10.180.218.229 with SMTP id pj5mr2959845wic.85.1423640703135; Tue, 10 Feb 2015 23:45:03 -0800 (PST) Original-Received: by 10.27.131.5 with HTTP; Tue, 10 Feb 2015 23:44:42 -0800 (PST) In-Reply-To: <87mw4lnked.fsf@uwakimon.sk.tsukuba.ac.jp> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c03::232 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:182866 Archived-At: On Tue, Feb 10, 2015 at 11:26 PM, Stephen J. Turnbull wrote: > BTW, in my usage, the only thing that lldb lacks that gdb has is my > muscle memory (lldb's command set is much more regular, but therefore > *different* and I haven't memorized it yet, partly because muscle- > memory-compatible aliases are provided for the most common commands > like "run", "backtrace", and "break"). I'm not a "power debugger" in > C, so it doesn't surprise me that you find lldb less satisfactory. > But this difference indicates you should be careful to worry about the > "innovator's dilemma", where an inferior product is "cheaper" (in some > sense) and takes over the non-power-user market, and in that way gains > the resources needed to improve rapidly and decisively. For the record, as another "power debugger" (mostly for programs I do not have debugging information for, and often not the source code either) - LLDB's command set is more regular, but also far more verbose; their own GDB to LLDB command map[1] assigns almost every operation a longer command on the LLDB side. Its Python API is a set of autogenerated C++ bindings with a few Python-specific helpers added, which unsurprisingly therefore feels quite clunky and poorly adapted to Python; there are also a bunch of obvious missing features in the API, requiring scripts to resort to the 'evaluate CLI command' function. It does not have any ability to do basic scripting directly from the debugger CLI (i.e. if/while commands), requiring you to use Python; while Python scripts (written against either API) are obviously far more powerful than raw GDB commands in the context of published, reusable entities, I often use GDB scripting interactively. It is, at least on OS X, highly buggy, and prone to hanging; in my experience GDB is typically quite buggy as well when asked to do semi-unusual things, but LLDB is no better. LLDB does not support hardware breakpoints on OS X despite this being its flagship platform, and it only recently gained support for a JIT symbol API. It does not support reverse debugging. I expect LLDB will improve significantly in the coming years, but currently I believe GDB is still technically superior. Hopefully it will keep sufficient pace to remain that way. [1] http://lldb.llvm.org/lldb-gdb.html