Skip to content

[lldb] Reword the "line 0" warning #116827

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Nov 20, 2024
Merged

[lldb] Reword the "line 0" warning #116827

merged 3 commits into from
Nov 20, 2024

Conversation

labath
Copy link
Collaborator

@labath labath commented Nov 19, 2024

We got a bug report that this message is confusing. In this particular case, the line zero was due to compiler tail merging (in optimized code). The main issue was the "no source code" part: in this case it's kind of incorrect because -- even though we can't really know that -- the address is arguably associated with multiple lines of source code.

I've tried to make the new wording more neutral, and added a wink towards compiler optimizations. I left out the "compiler generated" part of the message because I couldn't find a way to squeeze that in nicely. I'm also not entirely sure what it was referring to -- if this was (just) function prologue/epilogue, then maybe leaving it out is fine, as we're not likely to stop there anyway (?)

I also left out the function name, because:

  • for template functions it gets rather long
  • it's already present in the message, potentially twice (once in the "frame summary" line and once in the snippet of code we show for the function declaration)

@labath labath requested a review from medismailben November 19, 2024 16:16
@labath labath requested a review from JDevlieghere as a code owner November 19, 2024 16:16
@llvmbot llvmbot added the lldb label Nov 19, 2024
@llvmbot
Copy link
Member

llvmbot commented Nov 19, 2024

@llvm/pr-subscribers-lldb

Author: Pavel Labath (labath)

Changes

We got a bug report that this message is confusing. In this particular case, the line zero was due to compiler tail merging (in optimized code). The main issue was the "no source code" part: in this case it's kind of incorrect because -- even though we can't really know that -- the address is arguably associated with multiple lines of source code.

I've tried to make the new wording more neutral, and added a wink towards compiler optimizations. I left out the "compiler generated" part of the message because I couldn't find a way to squeeze that in nicely. I'm also not entirely sure what it was referring to -- if this was (just) function prologue/epilogue, then maybe leaving it out is fine, as we're not likely to stop there anyway (?)

I also left out the function name, because:

  • for template functions it gets rather long
  • it's already present in the message, potentially twice (once in the "frame summary" line and once in the snippet of code we show for the function declaration)

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

2 Files Affected:

  • (modified) lldb/source/Target/StackFrame.cpp (+3-13)
  • (modified) lldb/test/API/source-manager/TestSourceManager.py (+2-2)
diff --git a/lldb/source/Target/StackFrame.cpp b/lldb/source/Target/StackFrame.cpp
index 1bca9786fb7c70..ece85a077385ed 100644
--- a/lldb/source/Target/StackFrame.cpp
+++ b/lldb/source/Target/StackFrame.cpp
@@ -2007,19 +2007,9 @@ bool StackFrame::GetStatus(Stream &strm, bool show_frame_info, bool show_source,
           if (num_lines != 0)
             have_source = true;
           // TODO: Give here a one time warning if source file is missing.
-          if (!m_sc.line_entry.line) {
-            ConstString fn_name = m_sc.GetFunctionName();
-
-            if (!fn_name.IsEmpty())
-              strm.Printf(
-                  "Note: this address is compiler-generated code in function "
-                  "%s that has no source code associated with it.",
-                  fn_name.AsCString());
-            else
-              strm.Printf("Note: this address is compiler-generated code that "
-                          "has no source code associated with it.");
-            strm.EOL();
-          }
+          if (!m_sc.line_entry.line)
+            strm << "Note: This address is not associated with a specific line "
+                    "of code. This may be due to compiler optimizations.\n";
         }
       }
       switch (disasm_display) {
diff --git a/lldb/test/API/source-manager/TestSourceManager.py b/lldb/test/API/source-manager/TestSourceManager.py
index 7071f094e20f7e..ca415626f0d74c 100644
--- a/lldb/test/API/source-manager/TestSourceManager.py
+++ b/lldb/test/API/source-manager/TestSourceManager.py
@@ -336,8 +336,8 @@ def test_artificial_source_location(self):
                 "stop reason = breakpoint",
                 f"{src_file}:0",
                 "static int foo();",
-                "Note: this address is compiler-generated code in function",
-                "that has no source code associated with it.",
+                "Note: This address is not associated with a specific line "
+                "of code. This may be due to compiler optimizations."
             ],
         )
 

Copy link

github-actions bot commented Nov 19, 2024

✅ With the latest revision this PR passed the Python code formatter.

We got a bug report that this message is confusing.  In this particular
case, the line zero was due to compiler tail merging (in optimized
code). The main issue was the "no source code" part: in this case it's
kind of incorrect because -- even though we can't really know that --
the address is arguably associated with *multiple* lines of source code.

I've tried to make the new wording more neutral, and added a wink
towards compiler optimizations. I left out the "compiler generated" part
of the message because I couldn't find a way to squeeze that in nicely.
I'm also not entirely sure what it was referring to -- if this was
(just) function prologue/epilogue, then maybe leaving it out is fine, as
we're not likely to stop there anyway (?)

I also left out the function name, because:
- for template functions it gets rather long
- it's already present in the message, potentially twice (once in the
  "frame summary" line and once in the snippet of code we show for the
  function declaration)
Copy link
Collaborator

@DavidSpickett DavidSpickett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

For an expert this wording can imply that the previous wording might be the case, and for the non-experts it's less misleading.

labath and others added 2 commits November 20, 2024 08:54
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
@labath labath merged commit 0394e08 into llvm:main Nov 20, 2024
7 checks passed
@labath labath deleted the warn branch November 20, 2024 08:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants