[Bug tools/23673] TEST ./tests/backtrace-dwarf fails on s390x in at least 0.173

["michael.hudson at canonical dot com" <sourceware-bugzilla at sourceware dot org>]

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.