emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Contributing LLVM.org patches to gud.el


From: Nicholas Allegra
Subject: Re: Contributing LLVM.org patches to gud.el
Date: Wed, 11 Feb 2015 02:44:42 -0500

On Tue, Feb 10, 2015 at 11:26 PM, Stephen J. Turnbull
<address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]