From e22a1fbe18fe8039137382655ca131c614aa808d Mon Sep 17 00:00:00 2001 From: Alan Wu Date: Mon, 16 Jan 2023 14:25:39 -0500 Subject: addr2line.c: Don't special-case DWARF 5 parsing with GCC While trying to fix YJIT's symbol hygiene issue over at GH-7115, I found that addr2line.c's DWARF 5 parsing is half-disabled when building with GCC. Rust's output contains some DW_AT_rnglists_base records, which the disabled code reads. Without DW_AT_rnglists_base, it crashes when generating a backtrace. In common Ruby build configurations, GCC opts to only use DW_FORM_sec_offset for the range lists, and so it doesn't generate DW_AT_rnglists_base records, so consuming GCC's DWARF 5 while building with GCC was not a problem. However, even when building with GCC, we might need to parse DWARF 5 generated by other compilers at runtime. They could come from C extensions built by Clang, or come from Rust extensions. This can happen even when building without YJIT. --- addr2line.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) (limited to 'addr2line.c') diff --git a/addr2line.c b/addr2line.c index f7d5b0239b..4ac330772e 100644 --- a/addr2line.c +++ b/addr2line.c @@ -1725,10 +1725,6 @@ di_read_cu(DebugInfoReader *reader) di_read_debug_abbrev_cu(reader); if (di_read_debug_line_cu(reader)) return -1; -#if defined(__GNUC__) && !defined(__clang__) && !defined(__INTEL_COMPILER_BUILD_DATE) - /* Though DWARF specifies "the applicable base address defaults to the base - address of the compilation unit", but GCC seems to use zero as default */ -#else do { DIE die; @@ -1779,7 +1775,7 @@ di_read_cu(DebugInfoReader *reader) break; } } while (0); -#endif + return 0; } -- cgit v1.2.1