[lldb] Highlight basenames in backtraces

[Michael137]

Also changes the PC value color so it doesn't visually clash with the function names

Before:

After:

[llvmbot]

@llvm/pr-subscribers-lldb

Author: Michael Buch (Michael137)

Changes

Before:
<img width="1510" alt="Screenshot 2025-04-25 at 10 38 58 AM" src="https://github.com/user-attachments/assets/1ec35ba3-a3d9-4e5b-bac9-fc738bfe6d25" />

After:
<img width="1510" alt="Screenshot 2025-04-25 at 10 37 15 AM" src="https://github.com/user-attachments/assets/9358a8bc-5f8d-45f3-8f11-6b06954cc75e" />

---

Full diff: https://github.com/llvm/llvm-project/pull/137301.diff

2 Files Affected:

• (modified) lldb/source/Core/CoreProperties.td (+2-2)
• (modified) lldb/source/Plugins/Language/CPlusPlus/LanguageCPlusPlusProperties.td (+1-1)

diff --git a/lldb/source/Core/CoreProperties.td b/lldb/source/Core/CoreProperties.td
index f5d86b663de13..8c2ff934330b9 100644
--- a/lldb/source/Core/CoreProperties.td
+++ b/lldb/source/Core/CoreProperties.td
@@ -59,7 +59,7 @@ let Definition = "debugger" in {
     Desc<"The default disassembly format string to use when disassembling instruction sequences.">;
   def FrameFormat: Property<"frame-format", "FormatEntity">,
     Global,
-    DefaultStringValue<"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">,
+    DefaultStringValue<"frame #${frame.index}: ${frame.pc}{ ${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">,
     Desc<"The default frame format string to use when displaying stack frame information for threads.">;
   def NotiftVoid: Property<"notify-void", "Boolean">,
     Global,
@@ -215,7 +215,7 @@ let Definition = "debugger" in {
     Desc<"If true, LLDB will automatically escape non-printable and escape characters when formatting strings.">;
   def FrameFormatUnique: Property<"frame-format-unique", "FormatEntity">,
     Global,
-    DefaultStringValue<"frame #${frame.index}: ${ansi.fg.yellow}${frame.pc}${ansi.normal}{ ${module.file.basename}{`${function.name-without-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">,
+    DefaultStringValue<"frame #${frame.index}: ${frame.pc}{ ${module.file.basename}{`${function.name-without-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">,
     Desc<"The default frame format string to use when displaying stack frame information for threads from thread backtrace unique.">;
   def ShowAutosuggestion: Property<"show-autosuggestion", "Boolean">,
     Global,
diff --git a/lldb/source/Plugins/Language/CPlusPlus/LanguageCPlusPlusProperties.td b/lldb/source/Plugins/Language/CPlusPlus/LanguageCPlusPlusProperties.td
index 6ec87afe25758..348de256b154a 100644
--- a/lldb/source/Plugins/Language/CPlusPlus/LanguageCPlusPlusProperties.td
+++ b/lldb/source/Plugins/Language/CPlusPlus/LanguageCPlusPlusProperties.td
@@ -3,6 +3,6 @@ include "../../../../include/lldb/Core/PropertiesBase.td"
 let Definition = "language_cplusplus" in {
   def FunctionNameFormat: Property<"function-name-format", "FormatEntity">,
     Global,
-    DefaultStringValue<"${function.return-left}${function.scope}${function.basename}${function.template-arguments}${function.formatted-arguments}${function.return-right}${function.qualifiers}">,
+    DefaultStringValue<"${function.return-left}${function.scope}${ansi.fg.yellow}${function.basename}${ansi.normal}${function.template-arguments}${function.formatted-arguments}${function.return-right}${function.qualifiers}">,
     Desc<"C++ specific frame format string to use when displaying stack frame information for threads.">;
 }

[labath]

I kinda like how the (highlighted) PC value creates a column. What would you say to highlighting both?

(I know I can change this locally if I want to, so this is really a question what's a better default => don't change this just because I said so)

[Michael137]

I kinda like how the (highlighted) PC value creates a column. What would you say to highlighting both?

(I know I can change this locally if I want to, so this is really a question what's a better default => don't change this just because I said so)

This is what it would look like

Maybe we could use a different color? Don't have strong opinions on this.

[adrian-prantl]

I kinda like how the (highlighted) PC value creates a column. What would you say to highlighting both?

Maybe we could use a different color? Don't have strong opinions on this.

We could try a less aggressive color like the one used for the file names. I'm wondering if whoever came up with the current color scheme was trying to use a uniform color for all numbers. Even if so, that's not necessarily a property we need to preserve.

When discussing color changes, it might be best to show screenshots of a "default" gray-on-white and a black-on-white terminal (i.e., the "Basic" and "Pro" presets in Terminal.app) to get a better idea of what it will look like with a spectrum of widely-used color schemes.

[Michael137]

Here's a version where the PC value is cyan (like the filename):

You still get the colored column, but it feels less difficult on the eyes than having both yellow

This is on the "Default" scheme in the Terminal.app.

This is on the "Pro" scheme:

[augusto2112]

How does this look in a light terminal background?

[chelcassanova]

I agree with Pavel, having the PC highlighted in yellow (or really in a colour that stands out) and having that column centers everything IMO. e.g. I like the cyan, but in the "Pro" scheme since it stands out from everything else.

[JDevlieghere]

I tried the current state of the patch under Solarized dark and in Terminal.app with the default color scheme:

Both look fine to me 👍

[adrian-prantl]

I think this works.

[adrian-prantl]

Not to derail this too much, but I'm also thinking if we should stop coloring the column number. Happy to open a patch if people think this is a good idea?

[medismailben]

Not to derail this too much, but I'm also thinking if we should stop coloring the column number. Happy to open a patch if people think this is a good idea?

I don't have a strong opinion on this but I'm curious on why coloring the column number is bothering you specifically 😜 ? Should we also stop coloring the line number then ?

[JDevlieghere]

I agree with @medismailben, the line number is super helpful (I copy/paste this into vim all the time) and visually it looks a bit weird without the column even thought it's not useful.

[labath]

This looks good. Thanks for trying it out.

[DavidSpickett]

@Michael137, in the second screenshot in the PR description, clang-21`clang-main has clang-main highlighted, but clang-21`main does not highlight main. dyld also doesn't highlight start but that could be a lack of the debug information needed.

Is that expected?

(I'm pretty busy right now otherwise I'd check for myself)

[Michael137]

@Michael137, in the second screenshot in the PR description, clang-21`clang-main has clang-main highlighted, but clang-21`main does not highlight main. dyld also doesn't highlight start but that could be a lack of the debug information needed.

Is that expected?

(I'm pretty busy right now otherwise I'd check for myself)

Yea the start and main cases are a bit special because the Mangled object that we get for them doesn't have a m_mangled member set. So there's nothing to demangle and nothing to deduce about where the name starts/ends. Maybe we can do something special for those cases, but I haven't thought about this much yet

[labath]

Maybe we should say that if the name is not mangled, the entire string is the name of the function (and so it should be highlighted)?

[Michael137]

Maybe we should say that if the name is not mangled, the entire string is the name of the function (and so it should be highlighted)?

That could work. Just need to audit in which cases we might set a demangled name without specifying it's mangled name too. If the demangled name happens to include arguments/return types/etc., highlighting those may get confusing. But not sure that ever happens