bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#66575: [PATCH] Gud lldb support


From: Mattias Engdegård
Subject: 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@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.






reply via email to

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