[lldb][DWARF] Only log address range error to verbose channel #144037
Conversation
Currently `LLDB_LOG_ERROR` always logs to the "always-on" channel (which prints to the console; this started with TBD). Attaching to LLDB spams the console with a bunch of these messages: ``` ... 2025-06-13 10:15:09.965660+0100 lldb[40872:3936672] [lldb] DIE(0x240901): DIE has no address range information 2025-06-13 10:15:09.965667+0100 lldb[40872:3936672] [lldb] DIE(0x240925): DIE has no address range information 2025-06-13 10:15:09.965672+0100 lldb[40872:3936672] [lldb] DIE(0x240942): DIE has no address range information 2025-06-13 10:15:09.965679+0100 lldb[40872:3936672] [lldb] DIE(0x24095e): DIE has no address range information 2025-06-13 10:15:09.965686+0100 lldb[40872:3936672] [lldb] DIE(0x240981): DIE has no address range information 2025-06-13 10:15:09.965694+0100 lldb[40872:3936672] [lldb] DIE(0x240993): DIE has no address range information 2025-06-13 10:15:09.965701+0100 lldb[40872:3936672] [lldb] DIE(0x2409a2): DIE has no address range information ... ``` AFAIU this is not a fatal error, so this patch downgrades it from "always-on" by logging only in "verbose" mode. It still seems pretty aggressive to log all `LLDB_LOG_ERROR` messages to the console, but this is a stop-gap until we want to do something about it.
|
@llvm/pr-subscribers-lldb Author: Michael Buch (Michael137) ChangesCurrently Attaching to LLDB spams the console with a bunch of these messages: AFAIU this is not a fatal error, so this patch downgrades it from "always-on" by logging only in "verbose" mode. It still seems pretty aggressive to log all Full diff: https://github.com/llvm/llvm-project/pull/144037.diff 1 Files Affected:
diff --git a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
index 5196ce89a2c13..4d091f4deeabe 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp
@@ -617,7 +617,7 @@ void DWARFDebugInfoEntry::BuildFunctionAddressRangeTable(
for (const auto &r : *ranges)
debug_aranges->AppendRange(GetOffset(), r.LowPC, r.HighPC);
} else {
- LLDB_LOG_ERROR(log, ranges.takeError(), "DIE({1:x}): {0}", GetOffset());
+ LLDB_LOG_ERRORV(log, ranges.takeError(), "DIE({1:x}): {0}", GetOffset());
}
}
|
|
✅ With the latest revision this PR passed the C/C++ code formatter. |
|
Example CU where we fail to get the address range info: |
|
Another thing that's confusing me is that this error only prints to the console when you attach to LLDB. E.g., This doesn't print the error: But, Will break on the error path, and the error is logged to the console.. |
|
Looks like this error just happens anytime we build the aranges table for a CU and the ? |
I said as much on the PR, and still think it's too aggressive to send all these errors to the system log.
That's probably fine. This code sounds like it could be relatively hot, so I feel slightly bad for doing another scan of the abbreviation just to do what we do anyway (ignore the DIE), but this may actually be faster than constructing the llvm::Error object. |
…rd declarations This fixes the error reported in llvm#144037. When computing the aranges table of a CU, LLDB would currently visit all `DW_TAG_subprogram` DIEs and check their `DW_AT_low_pc`/`DW_AT_high_pc`. If those don't exist it would error out and spam the console. Some subprograms (particularly forward declarations) don't have low/high pc attributes, so it's not really an "error". We should just ignore those DIEs.
…rd declarations This fixes the error reported in llvm#144037. When computing the aranges table of a CU, LLDB would currently visit all `DW_TAG_subprogram` DIEs and check their `DW_AT_low_pc`/`DW_AT_high_pc`. If those don't exist it would error out and spam the console. Some subprograms (particularly forward declarations) don't have low/high pc attributes, so it's not really an "error". We should just ignore those DIEs.
@JDevlieghere @adrian-prantl in case we want to revisit this. Last time we spoke about this @felipepiovezan suggested having a more explicit name for the macro (something in the spirit of
|
…rd declarations (#144059) This fixes the error reported in #144037. When computing the aranges table of a CU, LLDB would currently visit all `DW_TAG_subprogram` DIEs and check their `DW_AT_low_pc`/`DW_AT_high_pc`/`DW_AT_ranges` attributes. If those don't exist it would error out and spam the console. Some subprograms (particularly forward declarations) don't have low/high pc attributes, so it's not really an "error". See DWARFv5 spec section `3.3.3 Subroutine and Entry Point Locations`: ``` A subroutine entry may have either a DW_AT_low_pc and DW_AT_high_pc pair of attributes or a DW_AT_ranges attribute whose values encode the contiguous or non-contiguous address ranges, respectively, of the machine instructions generated for the subroutine (see Section 2.17 on page 51). ... A subroutine entry representing a subroutine declaration that is not also a definition does not have code address or range attributes. ``` We should just ignore those DIEs.
…on of forward declarations (#144059) This fixes the error reported in llvm/llvm-project#144037. When computing the aranges table of a CU, LLDB would currently visit all `DW_TAG_subprogram` DIEs and check their `DW_AT_low_pc`/`DW_AT_high_pc`/`DW_AT_ranges` attributes. If those don't exist it would error out and spam the console. Some subprograms (particularly forward declarations) don't have low/high pc attributes, so it's not really an "error". See DWARFv5 spec section `3.3.3 Subroutine and Entry Point Locations`: ``` A subroutine entry may have either a DW_AT_low_pc and DW_AT_high_pc pair of attributes or a DW_AT_ranges attribute whose values encode the contiguous or non-contiguous address ranges, respectively, of the machine instructions generated for the subroutine (see Section 2.17 on page 51). ... A subroutine entry representing a subroutine declaration that is not also a definition does not have code address or range attributes. ``` We should just ignore those DIEs.
…rd declarations (llvm#144059) This fixes the error reported in llvm#144037. When computing the aranges table of a CU, LLDB would currently visit all `DW_TAG_subprogram` DIEs and check their `DW_AT_low_pc`/`DW_AT_high_pc`/`DW_AT_ranges` attributes. If those don't exist it would error out and spam the console. Some subprograms (particularly forward declarations) don't have low/high pc attributes, so it's not really an "error". See DWARFv5 spec section `3.3.3 Subroutine and Entry Point Locations`: ``` A subroutine entry may have either a DW_AT_low_pc and DW_AT_high_pc pair of attributes or a DW_AT_ranges attribute whose values encode the contiguous or non-contiguous address ranges, respectively, of the machine instructions generated for the subroutine (see Section 2.17 on page 51). ... A subroutine entry representing a subroutine declaration that is not also a definition does not have code address or range attributes. ``` We should just ignore those DIEs.
Currently
LLDB_LOG_ERRORalways logs to the "always-on" channel (which prints to the console; this started with #111911).Attaching to LLDB on macOS spams the console with a bunch of these messages:
AFAIU this is not a fatal error, so this patch downgrades it from "always-on" by logging only in "verbose" mode.
It still seems pretty aggressive to log all
LLDB_LOG_ERRORmessages to the console, but this is a stop-gap until we want to do something about it.