[Libunwind-devel] gold linker completely breaks libunwind

[Milian Wolff]

Hello all,

I noticed today that gold completely breaks libunwind when you use it to link 
libunwind itself. I use "GNU gold (GNU Binutils 2.25.0) 1.11" and libunwind 
from current git master. Running the tests, 13 fail, some even crash:

=========================================
   libunwind 1.1: tests/test-suite.log
=========================================

# TOTAL: 34
# PASS:  19
# SKIP:  0
# XFAIL: 2
# FAIL:  13
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: Gtest-exc
===============

FAIL Gtest-exc (exit status: 139)

FAIL: Ltest-exc
===============

FAIL Ltest-exc (exit status: 139)

FAIL: Gtest-resume-sig
======================

FAIL Gtest-resume-sig (exit status: 139)

FAIL: Ltest-resume-sig
======================

FAIL Ltest-resume-sig (exit status: 139)

FAIL: Gtest-resume-sig-rt
=========================

FAIL Gtest-resume-sig-rt (exit status: 139)

FAIL: Ltest-resume-sig-rt
=========================

FAIL Ltest-resume-sig-rt (exit status: 139)

XFAIL: Gtest-dyn1
=================

Too many steps to the signal frame (22)
XFAIL Gtest-dyn1 (exit status: 255)

XFAIL: Ltest-dyn1
=================

Too many steps to the signal frame (22)
XFAIL Ltest-dyn1 (exit status: 255)

FAIL: Gtest-trace
=================

FAILURE: detected 6 errors
FAILURE: unw_step() loop and unw_backtrace() depths differ: 1 vs. 1
FAILURE: unw_step() loop and backtrace() depths differ: 1 vs. 1
FAILURE: unw_step() loop and unw_backtrace() depths differ: 0 vs. 0
FAILURE: unw_step() loop and backtrace() depths differ: 0 vs. 0
FAILURE: unw_step() loop and unw_backtrace() depths differ: 0 vs. 0
FAILURE: unw_step() loop and backtrace() depths differ: 0 vs. 0
FAIL Gtest-trace (exit status: 255)

FAIL: Ltest-trace
=================

FAILURE: detected 6 errors
FAILURE: unw_step() loop and unw_backtrace() depths differ: 1 vs. 1
FAILURE: unw_step() loop and backtrace() depths differ: 1 vs. 1
FAILURE: unw_step() loop and unw_backtrace() depths differ: 0 vs. 0
FAILURE: unw_step() loop and backtrace() depths differ: 0 vs. 0
FAILURE: unw_step() loop and unw_backtrace() depths differ: 0 vs. 0
FAILURE: unw_step() loop and backtrace() depths differ: 0 vs. 0
FAIL Ltest-trace (exit status: 255)

FAIL: test-async-sig
====================

FAILURE: unw_step() looping over 102 iterations
FAILURE: unw_step() looping over 102 iterations
FAILURE: unw_step() looping over 102 iterations
FAILURE: unw_step() looping over 102 iterations
FAILURE: unw_step() looping over 102 iterations
FAILURE: detected 5 errors
FAIL test-async-sig (exit status: 255)

FAIL: Ltest-varargs
===================

FAILURE: expected deeper backtrace.
FAIL Ltest-varargs (exit status: 1)

FAIL: Lrs-race
==============

FAIL Lrs-race (exit status: 134)

FAIL: run-coredump-unwind
=========================

test-coredump-unwind: _UCD_create('/tmp/libunwind-test-s6k7q4Z9sf/core*') 
failed
FAIL run-coredump-unwind (exit status: 1)

FAIL: run-coredump-unwind-mdi
=============================

test-coredump-unwind: _UCD_create('/tmp/libunwind-test-lUV0ju1WBb/core*') 
failed
FAIL run-coredump-unwind-mdi (exit status: 1)


I think the last two regarding coredump can be ignored, as I did not 
explicitly enable this feature in configure (shouldn't make check honor that 
and then skip the tests?).

A simple application that calls unw_backtrace shows the following debug 
output:

 >_ULx86_64_init_mem_validate: using msync to validate memory
 >_ULx86_64_init_local: (cursor=0x7fffe7233250)
                >access_mem: mem[00007fffe7232f48] -> 7f2cb0497d80
                >access_mem: mem[00007fffe7232f40] -> 7fffe7232e90
 >_ULx86_64_tdep_trace: begin ip 0x7f2cb0497d80 cfa 0x7fffe7232e90
     >trace_cache_create: allocated cache 0x7f2cb0492fe0
     >trace_cache_get: using cache 0x7f2cb0492fe0
  >_ULx86_64_tdep_trace: depth 0 cfa 0x7fffe7232e90 rip 0x7f2cb0497d7f rsp 
0x7fffe7232e90 rbp 0x7fffe7232ea0
    >trace_lookup: updating slot 14134 after 0 steps, replacing 0x0
                >access_mem: mem[00007fffe7232f48] <- 7f2cb0497d7f
                >access_mem: mem[00007fffe7232f18] <- 7fffe7232ea0
                >access_mem: mem[00007fffe7232f40] <- 7fffe7232e90
 >_ULx86_64_step: (cursor=0x7fffe7233250, ip=0x00007f2cb0497d80, 
cfa=0x00007fffe7232e90)
                >get_rs_cache: acquiring lock
              >_ULx86_64_dwarf_find_proc_info: looking for IP=0x7f2cb0497d7f
               >_ULx86_64_dwarf_callback: checking , base=0x0)
               >_ULx86_64_dwarf_callback: checking linux-vdso.so.1, 
base=0x7fffe73d2000)
               >_ULx86_64_dwarf_callback: checking /home/milian/projects/
compiled/other/lib/libunwind.so.8, base=0x7f2cb0495000)
               >_ULx86_64_dwarf_callback: found table `/home/milian/projects/
compiled/other/lib/libunwind.so.8': segbase=0x7f2cb04a5c28, len=89, 
gp=0x7f2cb04a6268, table_data=0x7f2cb04a5c34
               >lookup: e->start_ip_offset = ffffffffffff2968
               >lookup: e->start_ip_offset = ffffffffffff2208
               >lookup: e->start_ip_offset = ffffffffffff1b98
               >lookup: e->start_ip_offset = ffffffffffff1f48
               >lookup: e->start_ip_offset = ffffffffffff20a8
               >lookup: e->start_ip_offset = ffffffffffff2128
               >_ULx86_64_dwarf_search_unwind_table: ip=0x7f2cb0497d7f, 
start_ip=0xffffffffffff2128
 >_ULx86_64_dwarf_search_unwind_table: e->fde_offset = ffffffffffffefa0, 
segbase = 7f2cb04a5c28, debug_frame_base = 0, fde_addr = 7f2cb04a4bc8
            >_ULx86_64_dwarf_extract_proc_info_from_fde: FDE @ 0x7f2cb04a4bc8
                >put_rs_cache: unmasking signals/interrupts and releasing lock
               >_ULx86_64_dwarf_step: returning -10
             >_ULx86_64_step: dwarf_step() failed (ret=-10), trying frame-
chain
                >access_mem: mem[00007f2cb0497d80] -> 15e8df8948ee8948
                >access_mem: mem[00007f2cb0497d88] -> 483178c08500000f
              >is_plt_entry: ip=0x7f2cb0497d80 => 0x15e8df8948ee8948 
0x483178c08500000f, ret = 0
                >access_mem: mem[00007fffe7232f18] -> 7fffe7232ea0
                >access_mem: mem[00007fffe7232ea0] -> 0
 >_ULx86_64_step: [RBP=0x7fffe7232f18] = 0x7fffe7232ea0 (cfa = 0x7fffe7232e90) 
-> 0x0
                >access_mem: mem[00007fffe7232ea8] -> 0
 >_ULx86_64_step: Frame Chain [RIP=0x7fffe7232ea8] = 0x0
  >_ULx86_64_step: returning 1
   >trace_init_addr: frame va 7f2cb0497d7f type 1 last 0 cfa rbp+16 rbp @ 
cfa-16 rsp @ cfa-1
   >_ULx86_64_tdep_trace: frame va 7f2cb0497d7f type 1 last 0 cfa rbp+16 rbp @ 
cfa-16 rsp @ cfa-1
                >access_mem: mem[00007fffe7232ea8] -> 0
                >access_mem: mem[00007fffe7232ea0] -> 0
    >_ULx86_64_tdep_trace: new cfa 0x7fffe7232eb0 rip 0x0 rsp 0x7fffe7232eb0 
rbp 0x0
 >_ULx86_64_tdep_trace: returning 0, depth 0

Also, I notice that Valgrind spots some errors:

==13078== Syscall param msync(start) points to unaddressable byte(s)
==13078==    at 0x57B5B50: __msync_nocancel (in /usr/lib/libc-2.21.so)
==13078==    by 0x4026A5D: validate_mem (Ginit.c:137)
==13078==    by 0x4026A5D: access_mem (Ginit.c:171)
==13078==    by 0x4028211: dwarf_get (libunwind_i.h:167)
==13078==    by 0x4028211: _ULx86_64_step (Gstep.c:145)
==13078==    by 0x4028FE3: trace_init_addr (Gtrace.c:248)
==13078==    by 0x4028FE3: trace_lookup (Gtrace.c:330)
==13078==    by 0x4028FE3: _ULx86_64_tdep_trace (Gtrace.c:447)
==13078==    by 0x4025D9E: backtrace (backtrace.c:69)
==13078==    by 0x400DE7: Trace::fill(int) (trace.h:61)
==13078==    by 0x400C03: main (tst_trace.cpp:22)
==13078==  Address 0xffeffd000 is on thread 1's stack
==13078==  3096 bytes below stack pointer
==13078== 
==13078== Conditional jump or move depends on uninitialised value(s)
==13078==    at 0x4027E1B: _ULx86_64_step (Gstep.c:225)
==13078==    by 0x4028FE3: trace_init_addr (Gtrace.c:248)
==13078==    by 0x4028FE3: trace_lookup (Gtrace.c:330)
==13078==    by 0x4028FE3: _ULx86_64_tdep_trace (Gtrace.c:447)
==13078==    by 0x4025D9E: backtrace (backtrace.c:69)
==13078==    by 0x400DE7: Trace::fill(int) (trace.h:61)
==13078==    by 0x400C03: main (tst_trace.cpp:22)
==13078== 
==13078== Conditional jump or move depends on uninitialised value(s)
==13078==    at 0x4028B0E: _ULx86_64_tdep_trace (Gtrace.c:521)
==13078==    by 0x4025D9E: backtrace (backtrace.c:69)
==13078==    by 0x400DE7: Trace::fill(int) (trace.h:61)
==13078==    by 0x400C03: main (tst_trace.cpp:22)

If I use ld 2.25.0 instead, everything works fine and no tests except the 
coredump ones fail. I still see a valgrind warning though:

==24193== Syscall param msync(start) points to uninitialised byte(s)
==24193==    at 0x59D5B50: __msync_nocancel (in /usr/lib/libc-2.21.so)
==24193==    by 0x4E3993D: validate_mem (Ginit.c:137)
==24193==    by 0x4E3993D: access_mem (Ginit.c:171)
==24193==    by 0x4E3F2F9: dwarf_get (libunwind_i.h:167)
==24193==    by 0x4E3F2F9: apply_reg_state (Gparser.c:819)
==24193==    by 0x4E410C1: _ULx86_64_dwarf_find_save_locs (Gparser.c:907)
==24193==    by 0x4E4164D: _ULx86_64_dwarf_step (Gstep.c:34)
==24193==    by 0x4E3AA48: _ULx86_64_step (Gstep.c:71)
==24193==    by 0x4E3BEC3: trace_init_addr (Gtrace.c:248)
==24193==    by 0x4E3BEC3: trace_lookup (Gtrace.c:330)
==24193==    by 0x4E3BEC3: _ULx86_64_tdep_trace (Gtrace.c:447)
==24193==    by 0x4E38C7E: backtrace (backtrace.c:69)
==24193==    by 0x400DE7: Trace::fill(int) (trace.h:61)
==24193==    by 0x400C03: main (tst_trace.cpp:22)
==24193==  Address 0xffeffe000 is on thread 1's stack
==24193==  in frame #7, created by backtrace (backtrace.c:59)
==24193==  Uninitialised value was created by a stack allocation
==24193==    at 0x4E38C40: backtrace (backtrace.c:59)
==24193== 
==24193== Syscall param msync(start) points to unaddressable byte(s)
==24193==    at 0x59D5B50: __msync_nocancel (in /usr/lib/libc-2.21.so)
==24193==    by 0x4E3993D: validate_mem (Ginit.c:137)
==24193==    by 0x4E3993D: access_mem (Ginit.c:171)
==24193==    by 0x4E3A17B: dwarf_get (libunwind_i.h:167)
==24193==    by 0x4E3A17B: _ULx86_64_access_reg (Gregs.c:130)
==24193==    by 0x4E3F209: apply_reg_state (Gparser.c:759)
==24193==    by 0x4E410C1: _ULx86_64_dwarf_find_save_locs (Gparser.c:907)
==24193==    by 0x4E4164D: _ULx86_64_dwarf_step (Gstep.c:34)
==24193==    by 0x4E3AA48: _ULx86_64_step (Gstep.c:71)
==24193==    by 0x4E3BEC3: trace_init_addr (Gtrace.c:248)
==24193==    by 0x4E3BEC3: trace_lookup (Gtrace.c:330)
==24193==    by 0x4E3BEC3: _ULx86_64_tdep_trace (Gtrace.c:447)
==24193==    by 0x4E38C7E: backtrace (backtrace.c:69)
==24193==    by 0x400DE7: Trace::fill(int) (trace.h:61)
==24193==    by 0x400C03: main (tst_trace.cpp:22)
==24193==  Address 0xffeffd000 is on thread 1's stack
==24193==  1624 bytes below stack pointer

Can anyone reproduce this behavior? Is this a libunwind or a gold bug?

Bye
-- 
Milian Wolff
address@hidden
http://milianw.de

signature.asc
Description: This is a digitally signed message part.