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

Previous Next

Full log

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.

Previous Next

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