https://sourceware.org/bugzilla/show_bug.cgi?id=23673
--- Comment #21 from Michael Hudson-Doyle <michael.hudson at canonical dot com> --- (In reply to Mark Wielaard from comment #20) > (In reply to Michael Hudson-Doyle from comment #19) > > I see a similar looking failure on arm64 on Ubuntu 18.10: > > > > https://launchpadlibrarian.net/391377304/buildlog_ubuntu-cosmic-arm64. > > elfutils_0.170-0.5_BUILDING.txt.gz > > So, if possible could you build with current git or 0.174 + the patch from > comment #14 or commit 69d6e67eee30c483ba53a8e1da1b3568033e3ddecommit > 69d6e67eee30c483ba53a8e1da1b3568033e3dde Oh hmm current git passes! Sorry for the noise. Oh and obviously f881459ffc95b6fad51aa055a158ee14814073aa fixes this (somehow I failed to read the git log correctly and had to bisect to find it but there's no real excuse for that). > > I've gdb-ed this to the point that the key difference between a working > > system (Ubuntu 18.04) and the failing one is that libc.so.6 has a lot more > > entries in .eh_frame_hdr in the failing system. On 18.04 it fails to find a > > fde for abort() (or raise, I think) and unwinds using .debug_frame and that > > succeeds. On 18.10 it finds a fde for both raise and abort but fails to > > successfully unwind past abort using it. I don't know either why the newer > > libc.so.6 has a bigger eh_frame_hdr (it is glibc 2.28 vs 2.27 but also built > > with newer gcc and binutils) or why unwinding using eh_frame info fails. > > In principle the .eh_frame and .debug_frame should provide the same CFI, > although encoded slightly differently. Maybe there is a difference? You > should be able to find both with eu-readelf --debug-dump=frame I wrote most of what follows while waiting for the test run above to complete but for the record... So something I forgot to mention is that the newer glibc has no .debug_frame (not even in the /usr/lib/debug file that has the other debug data). So in a sense the fact that elfutils is trying to unwind using eh_frame and not trying the debug_frame data at all is actually not relevant here. That said, here is the debug_frame CFI from libc in the working environment: [ 3d28] FDE length=36 cie=[ 3d18] CIE_pointer: 15640 initial_location: +0x0000000000033760 <abort> address_range: 0x228 Program: advance_loc 1 to 0x4 def_cfa_offset 320 offset r29 (x29) at cfa-320 offset r30 (x30) at cfa-312 advance_loc 2 to 0xc def_cfa_register r29 (x29) advance_loc 1 to 0x10 offset r19 (x19) at cfa-304 offset r20 (x20) at cfa-296 And here is the eh_frame CFI from the libc that fails: [ 2b08] FDE length=28 cie=[ 0] CIE_pointer: 11020 initial_location: +0x00000000000207d8 <abort> (offset: 0x207d8) address_range: 0x214 (end offset: 0x209ec) Program: advance_loc 1 to 0x207dc def_cfa_offset 320 offset r29 (x29) at cfa-320 offset r30 (x30) at cfa-312 advance_loc 4 to 0x207ec offset r19 (x19) at cfa-304 offset r20 (x20) at cfa-296 nop nop I guess it's the lack of the def_cfa_register r29 in the eh_frame data that is making the difference. -- You are receiving this mail because: You are on the CC list for the bug.
