[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.
- bug#66575: [PATCH] Gud lldb support, Gerd Möllmann, 2023/10/16
- bug#66575: [PATCH] Gud lldb support, Mattias Engdegård, 2023/10/16
- bug#66575: [PATCH] Gud lldb support, Gerd Möllmann, 2023/10/16
- bug#66575: [PATCH] Gud lldb support, Mattias Engdegård, 2023/10/17
- bug#66575: [PATCH] Gud lldb support, Gerd Möllmann, 2023/10/17
- bug#66575: [PATCH] Gud lldb support, Mattias Engdegård, 2023/10/17
- bug#66575: [PATCH] Gud lldb support, Gerd Möllmann, 2023/10/17
- bug#66575: [PATCH] Gud lldb support,
Mattias Engdegård <=
- bug#66575: [PATCH] Gud lldb support, Gerd Möllmann, 2023/10/17
- bug#66575: [PATCH] Gud lldb support, Gerd Möllmann, 2023/10/17
- bug#66575: [PATCH] Gud lldb support, Gerd Möllmann, 2023/10/17
- bug#66575: [PATCH] Gud lldb support, Mattias Engdegård, 2023/10/17
- bug#66575: [PATCH] Gud lldb support, Gerd Möllmann, 2023/10/17