From 9669d0859b38b41692fd48129fb43a1fb6d9df0e Mon Sep 17 00:00:00 2001 From: Ingo Weinhold Date: Sat, 7 Nov 2009 20:55:21 +0000 Subject: [PATCH] GCC 2 .eh_frame: The CIE offset in an FDE isn't always relative to the beginning of the section, but probably relative to the beginning of the data for the respective compilation unit (which might even make it useful again, since it could be used as negative offset to the CIE). Relaxed the check even more, so we always override the CIE offset when parsing .eh_frame sections. This makes the variables appear in another test app Axel kindly provided. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33941 a95241bf-73f2-0310-859d-f6bbb57e9c96 --- src/apps/debugger/dwarf/DwarfFile.cpp | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/apps/debugger/dwarf/DwarfFile.cpp b/src/apps/debugger/dwarf/DwarfFile.cpp index 7f31bb0d9e..5e919968a6 100644 --- a/src/apps/debugger/dwarf/DwarfFile.cpp +++ b/src/apps/debugger/dwarf/DwarfFile.cpp @@ -461,9 +461,11 @@ DwarfFile::UnwindCallFrame(CompilationUnit* unit, return B_BAD_DATA; // For some reason gcc 2.95.3 doesn't write the CIE offset, but - // always the offset of this entry's CIE pointer field. We fix - // it. - if (fUsingEHFrameSection && cieID == (uint64)lengthOffset) + // always the offset of this entry's CIE pointer field + // (probably even relative to the start of the data for the + // respective compilation unit). We simply assume the previous + // CIE we encountered is the right one. + if (fUsingEHFrameSection) cieID = previousCIE; TRACE_CFI(" found fde: length: %llu (%lld), CIE offset: %llu, "