GNU bug report logs - #66575
[PATCH] Gud lldb support

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 66575 in the body.
You can then email your comments to 66575 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Gud lldb support
Date: Mon, 16 Oct 2023 14:00:07 +0200

[Message part 1 (text/plain, inline)]

Tags: patch

The attached patch implements LLDB support in Gud, based on gud-gdb.
No MI support, because lldb-mi is no longer part of LLVM.

It's probably not needless to emphasize that this is entirely my work
alone :-).

[0001-Gud-lldb-support.patch (text/patch, attachment)]

Message #8 received at 66575 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 66575 <at> debbugs.gnu.org
Subject: bug#66575: [PATCH] Gud lldb support
Date: Mon, 16 Oct 2023 15:30:23 +0200

> No MI support, because lldb-mi is no longer part of LLVM.

So what is the currently blessed way to communicate with LLDB?

I only have comments about trivialities here; someone else should deal with the serious stuff.

> +(eval-when-compile (require 'rx))

There is usually no need to import rx explicitly. The necessary macros and functions are autoloaded.

> +;; because gud-symbol uses their values if they are present.  Tehir
> +;; names are deducded from the minor-mode name.

'Their', 'deduced'.

> +         ;;     frame #0: ...) at emacs.c:1310:9 [opt]
> +         (string-match (rx (and line-start (0+ blank) "frame"
> +                                (0+ not-newline) " at "
> +                                (group (1+ (not (any ":"))))
> +                                ":"


(You can write (not ":") instead of (not (any ":")) if you like.)
If the file name can have an absolute directory part, then it may run into trouble on Windows (C:\Some\Dir\File.c).

Sad that we throw away the column number here, but perhaps that's just a limitation of gud.el.

Anyway, a big step up from not having any support at all. Thank you!

Would you include a NEWS entry as well?

Message #11 received at 66575 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 66575 <at> debbugs.gnu.org
Subject: Re: bug#66575: [PATCH] Gud lldb support
Date: Mon, 16 Oct 2023 15:57:17 +0200

You probably want to include 'lldb' in more places in gud.el. For example:

> (defgroup gud nil
>   "The \"Grand Unified Debugger\" interface.
> Supported debuggers include gdb, sdb, dbx, xdb, perldb,
> pdb (Python), and jdb."

and in gud-text-menu-bar-map, gud-menu-map, etc.

Message #14 received at 66575 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 66575 <at> debbugs.gnu.org
Subject: Re: bug#66575: [PATCH] Gud lldb support
Date: Mon, 16 Oct 2023 16:09:38 +0200

[Message part 1 (text/plain, inline)]

Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

>> No MI support, because lldb-mi is no longer part of LLVM.
>
> So what is the currently blessed way to communicate with LLDB?

Don't really know, I'm afraid.

> I only have comments about trivialities here; someone else should deal
> with the serious stuff.
>
>> +(eval-when-compile (require 'rx))
>
> There is usually no need to import rx explicitly. The necessary macros
> and functions are autoloaded.
>
>> +;; because gud-symbol uses their values if they are present.  Tehir
>> +;; names are deducded from the minor-mode name.
>
> 'Their', 'deduced'.
>
>> +         ;;     frame #0: ...) at emacs.c:1310:9 [opt]
>> +         (string-match (rx (and line-start (0+ blank) "frame"
>> +                                (0+ not-newline) " at "
>> +                                (group (1+ (not (any ":"))))
>> +                                ":"
>
>
> (You can write (not ":") instead of (not (any ":")) if you like.)

Both Fixed in the attached patch.  I also found another spelling error
in an option passed to 'breakpoint set -joint...'.

> If thñe file name can have an absolute directory part, then it may run
> into trouble on Windows (C:\Some\Dir\File.c).

I guess I'll leave that as an exercise for someone having Windows :-).

>
> Sad that we throw away the column number here, but perhaps that's just
> a limitation of gud.el.

Indeed.

>
> Anyway, a big step up from not having any support at all. Thank you!

👍

>
> Would you include a NEWS entry as well?

When I get this into master, yes of course.  I'm not yet convinced of
that :-).

[0001-Gud-lldb-support.patch (text/x-patch, attachment)]

Message #17 received at 66575 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 66575 <at> debbugs.gnu.org
Subject: Re: bug#66575: [PATCH] Gud lldb support
Date: Mon, 16 Oct 2023 16:46:57 +0200

> You probably want to include 'lldb' in more places in gud.el. For example:
> 
>> (defgroup gud nil
>>  "The \"Grand Unified Debugger\" interface.
>> Supported debuggers include gdb, sdb, dbx, xdb, perldb,
>> pdb (Python), and jdb."
> 
> and in gud-text-menu-bar-map, gud-menu-map, etc.

And gud-tooltip-print-command, and probably more places.

Message #20 received at 66575 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 66575 <at> debbugs.gnu.org
Subject: Re: bug#66575: [PATCH] Gud lldb support
Date: Tue, 17 Oct 2023 10:15:58 +0200

[Message part 1 (text/plain, inline)]

Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

>> You probably want to include 'lldb' in more places in gud.el. For example:
>> 
>>> (defgroup gud nil
>>>  "The \"Grand Unified Debugger\" interface.
>>> Supported debuggers include gdb, sdb, dbx, xdb, perldb,
>>> pdb (Python), and jdb."
>> 
>> and in gud-text-menu-bar-map, gud-menu-map, etc.
>
> And gud-tooltip-print-command, and probably more places.

Thanks.

Please find a "final" patch attached.  This includes NEWS, manual, what
you mentioned and some other stuff.  I can't imagine that gud tooltips
for non-gdbmi have worked in the last decade or so...  Fortunately, I
don't have a system where I could test that :-).

[0001-Gud-lldb-support-bug-66575.patch (text/x-patch, attachment)]

Message #23 received at 66575 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 66575 <at> debbugs.gnu.org
Subject: Re: bug#66575: [PATCH] Gud lldb support
Date: Tue, 17 Oct 2023 11:00:35 +0200

16 okt. 2023 kl. 16.09 skrev Gerd Möllmann <gerd.moellmann <at> gmail.com>:

>> So what is the currently blessed way to communicate with LLDB?
> 
> Don't really know, I'm afraid.

Maybe it's worth a try anyway, since lldb-mi still seems maintained as a separate tool.
(But don't let it hold up your contribution -- it's useful on its own.)

>> If thñe file name can have an absolute directory part, then it may run
>> into trouble on Windows (C:\Some\Dir\File.c).
> 
> I guess I'll leave that as an exercise for someone having Windows :-).

I don't, but we could try to be nice anyway. What about replacing

  (group (1+ (not ":")))

with something like

  (group (opt (opt "\\\\?\\")         ; Windows fun
              (in "a-zA-Z") ":")      ; floppy letter
         (1+ (not ":")))

and ignore NTFS Alternate Data Streams, as we ignore the possibility of colons in file names on other systems?

Onto your most recent patch -- looks fine in general, only a few notes:

>  * Editing Changes in Emacs 30.1
>  
> ++++
> +** New command 'lldb'.

The text can be rearranged later on but this entry probably belongs under 'Changes in Specialized Modes and Packages'.

> +Run the LLDB debugger, analogous to the 'gud-gdb' command.  Note that
> +might want to add these settings to your .lldbinit file, to reduce the

Missing 'you' in the second sentence?

> +output in the LLDB output when stepping through source files.
> +
> +settings set stop-line-count-before 0
> +settings set stop-line-count-after 0

Indent these lines by 4 spaces (NEWS has its own formatting rules).

But shouldn't your new code issue these commands to lldb automatically? The user might not always run lldb under Emacs.

> +  ;; First line is the print command itself.
> +  (unless (string-match (regexp-quote (gud-tooltip-print-command ""))

Isn't this just (string-search ...) ? Or did you want a more precise match, in which case it probably should be anchored in some way and not just a substring search?

> +# This is for M-x lldb: don't show source lines when stopping.
> +settings set stop-line-count-before 0
> +settings set stop-line-count-after 0

As mentioned above, I'd hope we could do without this.

Message #26 received at 66575 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 66575 <at> debbugs.gnu.org
Subject: Re: bug#66575: [PATCH] Gud lldb support
Date: Tue, 17 Oct 2023 12:03:01 +0200

[Message part 1 (text/plain, inline)]

Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

> 16 okt. 2023 kl. 16.09 skrev Gerd Möllmann <gerd.moellmann <at> gmail.com>:
>
>>> So what is the currently blessed way to communicate with LLDB?
>> 
>> Don't really know, I'm afraid.
>
> Maybe it's worth a try anyway, since lldb-mi still seems maintained as a separate tool.
> (But don't let it hold up your contribution -- it's useful on its
> own.)

Maybe it would be worth it, don't know, but lldb-mi isn't even
installable via Homebrew at the moment...

>>> If thñe file name can have an absolute directory part, then it may run
>>> into trouble on Windows (C:\Some\Dir\File.c).
>> 
>> I guess I'll leave that as an exercise for someone having Windows :-).
>
> I don't, but we could try to be nice anyway. What about replacing
>
>   (group (1+ (not ":")))
>
> with something like
>
>   (group (opt (opt "\\\\?\\")         ; Windows fun
>               (in "a-zA-Z") ":")      ; floppy letter
>          (1+ (not ":")))
>
> and ignore NTFS Alternate Data Streams, as we ignore the possibility
> of colons in file names on other systems?

Hm.  I'd rather see someone run lldb on Windows, and tell us if it even
prints absolute file names.  It doesn't seem to do that on macOS.

> Onto your most recent patch -- looks fine in general, only a few notes:
>
>>  * Editing Changes in Emacs 30.1
>>  
>> ++++
>> +** New command 'lldb'.
>
> The text can be rearranged later on but this entry probably belongs under 'Changes in Specialized Modes and Packages'.
>
>> +Run the LLDB debugger, analogous to the 'gud-gdb' command.  Note that
>> +might want to add these settings to your .lldbinit file, to reduce the
>
> Missing 'you' in the second sentence?
>
>> +output in the LLDB output when stepping through source files.
>> +
>> +settings set stop-line-count-before 0
>> +settings set stop-line-count-after 0
>
> Indent these lines by 4 spaces (NEWS has its own formatting rules).

Fixed, and moved.  Thanks.

> But shouldn't your new code issue these commands to lldb automatically? The user might not always run lldb under Emacs.
>

I've thought about doing that as an initialization, but then it would
have to be manually undone once lldb is running, since .lldbinit is
loaded first, AFAIK, if enabled (default = no), which one could
suppress and load it later, but that might also not be what the user
wants. And so on...

So, to keep things simple, I'd rather leave the user's settings alone.
It doesn't make a difference, functionally.

>> +  ;; First line is the print command itself.
>> +  (unless (string-match (regexp-quote (gud-tooltip-print-command ""))
>
> Isn't this just (string-search ...) ? Or did you want a more precise
> match, in which case it probably should be anchored in some way and
> not just a substring search?

That's true.  I was too lazy to change that after experimenting with
this stuff :-).  I've changed that.

>> +# This is for M-x lldb: don't show source lines when stopping.
>> +settings set stop-line-count-before 0
>> +settings set stop-line-count-after 0
>
> As mentioned above, I'd hope we could do without this.

New version attached.  I guess I'll commit that soon :-).

[0001-Gud-lldb-support-bug-66575.patch (text/x-patch, attachment)]

Message #29 received at 66575 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 66575 <at> debbugs.gnu.org
Subject: Re: bug#66575: [PATCH] Gud lldb support
Date: Tue, 17 Oct 2023 13:21:41 +0200

17 okt. 2023 kl. 12.03 skrev Gerd Möllmann <gerd.moellmann <at> gmail.com>:

> Hm.  I'd rather see someone run lldb on Windows, and tell us if it even
> prints absolute file names.  It doesn't seem to do that on macOS.

So it seems. Odd. All right, let's use the simple pattern for now.
But doesn't this severely limit the ability of Emacs to locate the source file?
Surely there must be a way to retrieve the directory?

> I've thought about doing that as an initialization, but then it would
> have to be manually undone once lldb is running, since .lldbinit is
> loaded first, AFAIK, if enabled (default = no), which one could
> suppress and load it later, but that might also not be what the user
> wants. And so on...

Would you please explain this slowly to someone who's even less alert than usual this morning?

I got as far as understanding that the commands turn off the emission of source lines around the stopping position. Fine, and this is in general what we want if the source position is shown in an Emacs window.
But the user may have fine reasons for wanting to run lldb outside Emacs from time to time, and would then probably prefer the source lines in that case.

(Besides, I often don't see the position being tracked in a source buffer with your patch. Is this a matter of missing directory in the stop text?)

And here's a completely unrelated problem: the lldb command-line provides tab-completion on which I rely a lot as the command set is vast and my knowledge of it is spotty. Could it be provided in Emacs?

Message #32 received at 66575 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 66575 <at> debbugs.gnu.org
Subject: Re: bug#66575: [PATCH] Gud lldb support
Date: Tue, 17 Oct 2023 14:30:41 +0200

Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

> 17 okt. 2023 kl. 12.03 skrev Gerd Möllmann <gerd.moellmann <at> gmail.com>:
>
>> Hm.  I'd rather see someone run lldb on Windows, and tell us if it even
>> prints absolute file names.  It doesn't seem to do that on macOS.
>
> So it seems. Odd. All right, let's use the simple pattern for now.
> But doesn't this severely limit the ability of Emacs to locate the source file?
> Surely there must be a way to retrieve the directory?

There is this: https://lldb.llvm.org/use/formatting.html

TLDR is that one can customize what LLDB prints in certain situations.
The default is, AFAIU, and I'm not an LLDB expert at all, relative
paths.

>> I've thought about doing that as an initialization, but then it would
>> have to be manually undone once lldb is running, since .lldbinit is
>> loaded first, AFAIK, if enabled (default = no), which one could
>> suppress and load it later, but that might also not be what the user
>> wants. And so on...
>
> Would you please explain this slowly to someone who's even less alert.
> than usual this morning?

Sorry :-)

> I got as far as understanding that the commands turn off the emission
> of source lines around the stopping position.

Correct.

> Fine, and this is in
> general what we want if the source position is shown in an Emacs
> window.

At least that's what I find prettier, so I added my (our) personal
preferences to src/.lldbinit :-).

I didn't want to forsee what users want, that's all.

In general, I find it always surprising what scenarios users come up
with, and I dont't want to get into anyone's way.  You get from LLDB
what you configure for LLDB.

> But the user may have fine reasons for wanting to run lldb
> outside Emacs from time to time, and would then probably prefer the
> source lines in that case.

Could be, yes.  In that case they could use different init files, or
different LLDB config files, or write some Python (INSIDE_EMACS should
be in the environment when in Emacs), or...

> (Besides, I often don't see the position being tracked in a source
> buffer with your patch. Is this a matter of missing directory in the
> stop text?)

Can you give me an example that I can try to reproduce?  LLDB version
and output in these cases would be also be interesting.  I'm using
17.0.2 here on macOS 14.0.

> And here's a completely unrelated problem: the lldb command-line
> provides tab-completion on which I rely a lot as the command set is
> vast and my knowledge of it is spotty.

You're describing my situation :-).

> Could it be provided in Emacs?

Possibly.  Indeed, I've started looking at this, see etc/emacs_lldb.py,
function xcomplete, but I'm not there yet, because I don't fully
understand what the Python API used there guarantees to return, and the
documentation is silent, as usual.  (Although it did get better in many
areas recently, I have to admit.)

So, I'm either left with guessing, or looking at the C++ sources.
Anyway--chances are that I either find out, or pretend to have found out
at some point :-).

That would then come after the current stuff is committed, of course.

Message #35 received at 66575 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 66575 <at> debbugs.gnu.org
Subject: Re: bug#66575: [PATCH] Gud lldb support
Date: Tue, 17 Oct 2023 17:40:02 +0200

Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

> And here's a completely unrelated problem: the lldb command-line
> provides tab-completion on which I rely a lot as the command set is
> vast and my knowledge of it is spotty. Could it be provided in Emacs?

I've looked through LLDB's sources, and I've found out what the return
value of HandleCompletions means (see new comment in emacs_lldb.py in
master.  So, I'll definitely add that later.

I also kind of found what the preferred API of LLDB is, which I think
you asked earlier: I think it's C++.  LLDB is actually a library, and
the lldb executable itself is a thin wrapper using LLDB's C++ API to do
its job.  Likewise for other tools using LLDB.

I think the whole API is also available through Python, i.e. the classes
in the lldb module, like lldb.SBValue.  The API is pretty
under-documented though, also in C++.

Message #38 received at 66575 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 66575 <at> debbugs.gnu.org
Subject: Re: bug#66575: [PATCH] Gud lldb support
Date: Tue, 17 Oct 2023 18:18:26 +0200

17 okt. 2023 kl. 14.30 skrev Gerd Möllmann <gerd.moellmann <at> gmail.com>:

> There is this: https://lldb.llvm.org/use/formatting.html

That's excellent!

> The default is, AFAIU, and I'm not an LLDB expert at all, relative
> paths.

Indeed:

(lldb) settings show frame-format
frame-format (format-string) = "frame #${frame.index}: ${ansi.fg.yellow}${frame.pc}${ansi.normal}{ ${module.file.basename}{\`${function.name-with-args}{${frame.no-debug}${function.pc-offset}}}}{ at ${ansi.fg.cyan}${line.file.basename}${ansi.normal}:${ansi.fg.yellow}${line.number}${ansi.normal}{:${ansi.fg.yellow}${line.column}${ansi.normal}}}{${function.is-optimized} [opt]}{${frame.is-artificial} [artificial]}\n"

in which we note line.file.basename. We could modify frame-format and thread-stop-format to convey all the useful information in a format that is easy to parse.

> In general, I find it always surprising what scenarios users come up
> with, and I dont't want to get into anyone's way.  You get from LLDB
> what you configure for LLDB.

Sure, but not all settings are alike in that respect. The user definitely expects Emacs to take care of those that are pertinent to the interface. 

> Could be, yes.  In that case they could use different init files, or
> different LLDB config files, or write some Python (INSIDE_EMACS should
> be in the environment when in Emacs), or...

No, the source-attached init files should contain settings pertaining to peculiarities of the project, not to the lldb interaction mode.

> Can you give me an example that I can try to reproduce?  LLDB version
> and output in these cases would be also be interesting.  I'm using
> 17.0.2 here on macOS 14.0.

I have older macOS and LLDB versions but starting an empty emacs, M-x lldb attaching to another Emacs process and stopping somewhere that doesn't correspond to an open source buffer (eval.c, say) won't cause that file to be opened. Presumably it doesn't know where to look, given the use of line.file.basename in frame-format.

Anyway, your patch is fine to be committed -- any further improvement can be made later on, and actual users mean more people complaining. We shall give all of them your home address and telephone number.

Message #41 received at 66575 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 66575 <at> debbugs.gnu.org
Subject: Re: bug#66575: [PATCH] Gud lldb support
Date: Tue, 17 Oct 2023 18:27:48 +0200

17 okt. 2023 kl. 17.40 skrev Gerd Möllmann <gerd.moellmann <at> gmail.com>:

> I've looked through LLDB's sources, and I've found out what the return
> value of HandleCompletions means (see new comment in emacs_lldb.py in
> master.  So, I'll definitely add that later.

Sounds promising!

> I also kind of found what the preferred API of LLDB is, which I think
> you asked earlier: I think it's C++.  LLDB is actually a library, and
> the lldb executable itself is a thin wrapper using LLDB's C++ API to do
> its job.  Likewise for other tools using LLDB.

There is a DAP module for LLDB, apparently mostly written in Rust:

  https://github.com/vadimcn/codelldb

Message #44 received at 66575 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 66575 <at> debbugs.gnu.org
Subject: Re: bug#66575: [PATCH] Gud lldb support
Date: Tue, 17 Oct 2023 18:55:32 +0200

Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

> I have older macOS and LLDB versions but starting an empty emacs, M-x
> lldb attaching to another Emacs process and stopping somewhere that
> doesn't correspond to an open source buffer (eval.c, say) won't cause
> that file to be opened. Presumably it doesn't know where to look,
> given the use of line.file.basename in frame-format.

Not sure, but that could also be in Gud itself.  Do you have a Gdb
running so that we could check what gud-gdb does?

> Anyway, your patch is fine to be committed -- any further improvement
> can be made later on, and actual users mean more people
> complaining. We shall give all of them your home address and telephone
> number.

:-)

Message #47 received at 66575 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 66575 <at> debbugs.gnu.org
Subject: Re: bug#66575: [PATCH] Gud lldb support
Date: Tue, 17 Oct 2023 19:01:19 +0200

Mattias Engdegård <mattias.engdegard <at> gmail.com> writes:

>> I also kind of found what the preferred API of LLDB is, which I think
>> you asked earlier: I think it's C++.  LLDB is actually a library, and
>> the lldb executable itself is a thin wrapper using LLDB's C++ API to do
>> its job.  Likewise for other tools using LLDB.
>
> There is a DAP module for LLDB, apparently mostly written in Rust:
>
>   https://github.com/vadimcn/codelldb

AFAIK, llvm-vscode, which is part of LLDB, is also a DAP module.  But
that's C++, of course, so I'm not surprised that it needed a Rust
rewrite :-).

Message #50 received at 66575 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 66575 <at> debbugs.gnu.org
Subject: Re: bug#66575: [PATCH] Gud lldb support
Date: Tue, 17 Oct 2023 19:18:10 +0200

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

>
>> Anyway, your patch is fine to be committed -- any further improvement
>> can be made later on, and actual users mean more people
>> complaining. We shall give all of them your home address and telephone
>> number.
>
> :-)

Committed to master just now, and closing.
Thanks for the review, Matthias!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.