Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1154118 > unrolled thread

Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user Thorsten Glaser <tg@debian.org> - 2023-07-14 00:50 +0200
    Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Thorsten Glaser <tg@debian.org> - 2023-07-14 02:20 +0200
      Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Helge Deller <deller@gmx.de> - 2023-07-14 06:20 +0200
    Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user Ben Hutchings <ben@decadent.org.uk> - 2023-07-14 15:30 +0200
      Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user Michael Tokarev <mjt@tls.msk.ru> - 2023-07-14 15:40 +0200
      Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Thorsten Glaser <tg@debian.org> - 2023-07-14 20:50 +0200
        Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Michael Tokarev <mjt@tls.msk.ru> - 2023-07-14 21:40 +0200
          Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Thorsten Glaser <tg@debian.org> - 2023-07-14 22:20 +0200
            Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Michael Tokarev <mjt@tls.msk.ru> - 2023-07-14 22:30 +0200
              Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Thorsten Glaser <tg@debian.org> - 2023-07-15 00:20 +0200
                Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user Ben Hutchings <ben@decadent.org.uk> - 2023-07-15 23:50 +0200

#1154118 — Bug#1040981: klibc-utils: Segmentation fault while executin klibc binaries in armhf architecture under qemu-user

retitle 1040981 klibc-utils: segfault executing armhf binaries under qemu-user
thanks

Venkata.Pyla@toshiba-tsip.com dixit:

>Follow below steps to reproduce this issue
>```
>$ sudo debootstrap --arch=arm bookworm arm-bookworm-rootfs/ http://deb.debian.org/debian/
>$ sudo chroot arm-bookworm/ apt-update && apt install -y klibc-utils
>$ sudo chroot arm-bookworm/ /usr/lib/klibc/bin/fstype --help
>qemu: uncaught target signal 11 (Segmentation fault) - core dumped
>Segmentation fault
>```

Same when just copying klibc-m13AniKHUCMUNN8mXSUhIi8CUSA.so out
of libklibc_2.0.12-1_armhf.deb into /lib/ and extracting fstype
from klibc-utils_2.0.12-1_armhf.deb… however it works both on a
real-metal ARM box (amdahl.d.o) and a statically(!) linked mksh
against klibc :/

My guess here is that it’s, as usual, the fault of qemu-user,
which has multiple outstanding emulation bugs, some of which
affecting klibc-built binaries especially, though this, since
a statically linked mksh works, is probably an issue with how
qemu-user handles .interp *shrug*

Since your one-stage debootstrap succeeds, can you not do the
remaining steps booting into the image-under-preparation and
run them there? Here, qemu-system-armhf should probably suffice.
I know, it’s just as a workaround, until the people in question
figure out why this happens.

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.		-- Andreas Bogk über boehm-gc in d.a.s.r

[toc] | [next] | [standalone]

#1154124 — Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

Dixi quod…

>My guess here is that it’s, as usual, the fault of qemu-user,

Strong evidence for that: doesn’t look like it even executes
one bit of klibc code:

$ qemu-arm-static -d cpu ./fstype --help
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)

And:

GNU gdb (Debian 10.1-2) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/qemu-arm-static...
Downloading separate debug info for /usr/bin/qemu-arm-static...
Reading symbols from /home/tglase/.cache/debuginfod_client/5a14d0155c981c94a528d6468ded2c203f1e1908/debuginfo...
(gdb) r
Starting program: /usr/bin/qemu-arm-static ./fstype --help
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff7ff8700 (LWP 27273)]

Thread 1 "qemu-arm-static" received signal SIGSEGV, Segmentation fault.
0x00000000004c5cb6 in cpu_lduw_code (env=env@entry=0xcbed30, ptr=3670264) at ./include/qemu/bswap.h:329
Download failed: Invalid argument.  Continuing without source file ./b/user-static/./include/qemu/bswap.h.
329     ./include/qemu/bswap.h: No such file or directory.
(gdb) bt
#0  0x00000000004c5cb6 in cpu_lduw_code (env=env@entry=0xcbed30, ptr=3670264) at ./include/qemu/bswap.h:329
#1  0x000000000045c9ac in translator_lduw_swap (do_swap=false, pc=<optimized out>, env=0xcbed30)
    at ./include/exec/translator.h:178
#2  arm_lduw_code (sctlr_b=false, addr=<optimized out>, env=0xcbed30) at ../../target/arm/arm_ldst.h:44
#3  thumb_tr_translate_insn (dcbase=0x7fffffffdd50, cpu=<optimized out>) at ../../target/arm/translate.c:9054
#4  0x00000000004bc1e9 in translator_loop (ops=0xa7f180 <thumb_translator_ops>, db=db@entry=0x7fffffffdd50,
    cpu=cpu@entry=0xcb6a60, tb=tb@entry=0x7fffe8000040 <code_gen_buffer+22>, max_insns=max_insns@entry=512)
    at ../../accel/tcg/translator.c:103
#5  0x0000000000463eb3 in gen_intermediate_code (cpu=cpu@entry=0xcb6a60,
    tb=tb@entry=0x7fffe8000040 <code_gen_buffer+22>, max_insns=max_insns@entry=512)
    at ../../target/arm/translate.c:9283
#6  0x0000000000512d75 in tb_gen_code (cpu=cpu@entry=0xcb6a60, pc=3670264, cs_base=0, flags=1196288,
    cflags=-16777216, cflags@entry=0) at ../../accel/tcg/translate-all.c:1744
#7  0x00000000004b4734 in tb_find (cf_mask=0, tb_exit=0, last_tb=0x0, cpu=0xcb6a60)
    at ../../accel/tcg/cpu-exec.c:414
#8  cpu_exec (cpu=cpu@entry=0xcb6a60) at ../../accel/tcg/cpu-exec.c:770
#9  0x0000000000422608 in cpu_loop (env=env@entry=0xcbed30) at ../../linux-user/arm/cpu_loop.c:237
#10 0x0000000000402949 in main (argc=<optimized out>, argv=0x7fffffffe230, envp=<optimized out>)
    at ../../linux-user/main.c:882
(gdb) info r
rax            0x40d94000          1087979520
rbx            0x7fffffffdd50      140737488346448
rcx            0xd9a728            14264104
rdx            0xc64d60            12995936
rsi            0x3800f8            3670264
rdi            0xcbed30            13364528
rbp            0x0                 0x0
rsp            0x7fffffffdc48      0x7fffffffdc48
r8             0xc64d60            12995936
r9             0xc656e8            12998376
r10            0x0                 0
r11            0x0                 0
r12            0xcbed30            13364528
r13            0x0                 0
r14            0x0                 0
r15            0x7fffffffdd50      140737488346448
rip            0x4c5cb6            0x4c5cb6 <cpu_lduw_code+22>
eflags         0x10246             [ PF ZF IF RF ]
cs             0x33                51
ss             0x2b                43
ds             0x0                 0
es             0x0                 0
fs             0x0                 0
gs             0x0                 0
(gdb) disas
Dump of assembler code for function cpu_lduw_code:
   0x00000000004c5ca0 <+0>:     mov    QWORD PTR fs:0xffffffffffffff58,0x1
   0x00000000004c5cad <+13>:    mov    esi,esi
   0x00000000004c5caf <+15>:    mov    rax,QWORD PTR [rip+0x79efa2]        # 0xc64c58 <guest_base>
=> 0x00000000004c5cb6 <+22>:    movzx  eax,WORD PTR [rax+rsi*1]
   0x00000000004c5cba <+26>:    mov    QWORD PTR fs:0xffffffffffffff58,0x0
   0x00000000004c5cc7 <+39>:    ret    
End of assembler dump.


The content of rax (guest_base) looks legit:

$ cat /proc/27269/maps
00400000-00401000 r--p 00000000 fd:00 2624234                            /usr/bin/qemu-arm-static
00401000-0071e000 r-xp 00001000 fd:00 2624234                            /usr/bin/qemu-arm-static
0071e000-00a53000 r--p 0031e000 fd:00 2624234                            /usr/bin/qemu-arm-static
00a53000-00be8000 r--p 00652000 fd:00 2624234                            /usr/bin/qemu-arm-static
00be8000-00c62000 rw-p 007e7000 fd:00 2624234                            /usr/bin/qemu-arm-static
00c62000-00db7000 rw-p 00000000 00:00 0                                  [heap]
40d94000-40da4000 ---p 00000000 00:00 0
40da4000-40da5000 r--p 00000000 fd:00 2234167                            /home/tglase/fstype
40da5000-40da6000 rw-p 00000000 fd:00 2234167                            /home/tglase/fstype
40da6000-80d94000 ---p 00000000 00:00 0
80d94000-80d95000 ---p 00000000 00:00 0
80d95000-81595000 rw-p 00000000 00:00 0
81595000-140d84000 ---p 00000000 00:00 0
140d84000-140d85000 r--p 00000000 00:00 0
7fffe8000000-7fffeffff000 rwxp 00000000 00:00 0
7fffeffff000-7ffff0000000 ---p 00000000 00:00 0
7ffff0000000-7ffff0021000 rw-p 00000000 00:00 0
7ffff0021000-7ffff4000000 ---p 00000000 00:00 0
7ffff7777000-7ffff77f8000 rw-p 00000000 00:00 0
7ffff77f8000-7ffff77f9000 ---p 00000000 00:00 0
7ffff77f9000-7ffff7ff9000 rw-p 00000000 00:00 0
7ffff7ff9000-7ffff7ffd000 r--p 00000000 00:00 0                          [vvar]
7ffff7ffd000-7ffff7fff000 r-xp 00000000 00:00 0                          [vdso]
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0                          [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

rax+rsi is 0x411140F8 though, which isn’t currently mapped readable,
so the ptr argument (rsi) doesn’t lie in usable memory or so.

Does this help?:

(gdb) frame 4
#4  0x00000000004bc1e9 in translator_loop (ops=0xa7f180 <thumb_translator_ops>, db=db@entry=0x7fffffffdd50,
    cpu=cpu@entry=0xcb6a60, tb=tb@entry=0x7fffe8000040 <code_gen_buffer+22>, max_insns=max_insns@entry=512)
    at ../../accel/tcg/translator.c:103
Download failed: Invalid argument.  Continuing without source file ./b/user-static/../../accel/tcg/translator.c.
103     ../../accel/tcg/translator.c: No such file or directory.
(gdb) print *cpu
$2 = {parent_obj = {parent_obj = {class = 0xcab090, free = 0x615410 <g_free>, properties = 0xcab800, ref = 2,
      parent = 0xcaf8f0}, id = 0x0, canonical_path = 0xd52700 "/machine/unattached/device[0]", realized = true,
    pending_deleted_event = false, opts = 0x0, hotplugged = 0, allow_unplug_during_migration = false,
    parent_bus = 0x0, gpios = {lh_first = 0x0}, clocks = {lh_first = 0x0}, child_bus = {lh_first = 0x0},
    num_child_bus = 0, instance_id_alias = -1, alias_required_for_version = 0, reset = {count = 0,
      hold_phase_pending = false, exit_phase_in_progress = false}}, nr_cores = 1, nr_threads = 1, thread = 0x0,
  thread_id = 0, running = true, has_waiter = false, halt_cond = 0x0, thread_kicked = false, created = false,
  stop = false, stopped = false, start_powered_off = false, unplug = false, crash_occurred = false,
  exit_request = false, in_exclusive_context = false, cflags_next_tb = 4294967295, interrupt_request = 0,
  singlestep_enabled = 0, icount_budget = 0, icount_extra = 0, random_seed = 0, jmp_env = {{__jmpbuf = {
        13331040, -3916268391523349795, 13331040, 7528192, 14027408, 2, -3916268390873232675,
        3916268883799247581}, __mask_was_saved = 0, __saved_mask = {__val = {0 <repeats 16 times>}}}},
  work_mutex = {lock = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0,
        __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>,
      __align = 0}, initialized = true}, work_list = {sqh_first = 0x0, sqh_last = 0xcb6c30}, cpu_ases = 0x0,
  num_ases = 0, as = 0x0, memory = 0x0, env_ptr = 0xcbed30, icount_decr_ptr = 0xcbed28, tb_jmp_cache = {
    0x0 <repeats 4096 times>}, gdb_regs = 0xd4fe30, gdb_num_regs = 192, gdb_num_g_regs = 26, node = {
    tqe_next = 0x0, tqe_circ = {tql_next = 0x0, tql_prev = 0xbe8010 <cpus>}}, breakpoints = {tqh_first = 0x0,
    tqh_circ = {tql_next = 0x0, tql_prev = 0xcbec90}}, watchpoints = {tqh_first = 0x0, tqh_circ = {
      tql_next = 0x0, tql_prev = 0xcbeca0}}, watchpoint_hit = 0x0, opaque = 0xd74700, mem_io_pc = 0,
  kvm_fd = 0, kvm_state = 0x0, kvm_run = 0x0, trace_dstate_delayed = {0}, trace_dstate = {0}, plugin_mask = {
    0}, cpu_index = 0, cluster_index = -1, halted = 0, can_do_io = 1, exception_index = -1, vcpu_dirty = false,
  throttle_thread_scheduled = false, ignore_memory_transaction_failures = false, hax_vcpu = 0x0, hvf_fd = 0,
  iommu_notifiers = 0x0}
(gdb) print *db
$3 = {tb = 0x7fffe8000040 <code_gen_buffer+22>, pc_first = 3670264, pc_next = 3670264, is_jmp = DISAS_NEXT,
  num_insns = 1, max_insns = 512, singlestep_enabled = false}
(gdb) frame 9
#9  0x0000000000422608 in cpu_loop (env=env@entry=0xcbed30) at ../../linux-user/arm/cpu_loop.c:237
Download failed: Invalid argument.  Continuing without source file ./b/user-static/../../linux-user/arm/cpu_loop.c.
237     ../../linux-user/arm/cpu_loop.c: No such file or directory.
(gdb) print *env
$4 = {regs = {0, 1082133305, 1082133314, 0, 0, 0, 0, 0, 0, 0, 71688, 0, 0, 1082132928, 0, 3670264}, xregs = {
    0 <repeats 32 times>}, pc = 0, pstate = 0, aarch64 = 0, hflags = 1179648, uncached_cpsr = 16, spsr = 0,
  banked_spsr = {0, 0, 0, 0, 0, 0, 0, 0}, banked_r13 = {0, 0, 0, 0, 0, 0, 0, 0}, banked_r14 = {0, 0, 0, 0, 0,
    0, 0, 0}, usr_regs = {0, 0, 0, 0, 0}, fiq_regs = {0, 0, 0, 0, 0}, CF = 0, VF = 0, NF = 48, ZF = 1073741824,
  QF = 0, GE = 0, thumb = 1, condexec_bits = 0, btype = 0, daif = 0, elr_el = {0, 0, 0, 0}, sp_el = {0, 0, 0,
    0}, cp15 = {c0_cpuid = 1093648625, {{_unused_csselr0 = 0, csselr_ns = 0, _unused_csselr1 = 0,
        csselr_s = 0}, csselr_el = {0, 0, 0, 0}}, {{_unused_sctlr = 0, sctlr_ns = 12910712, hsctlr = 0,
        sctlr_s = 0}, sctlr_el = {0, 12910712, 0, 0}}, cpacr_el1 = 15728640, cptr_el = {0, 0, 0, 0},
    c1_xscaleauxcr = 0, sder = 0, nsacr = 0, {{_unused_ttbr0_0 = 0, ttbr0_ns = 0, _unused_ttbr0_1 = 0,
        ttbr0_s = 0}, ttbr0_el = {0, 0, 0, 0}}, {{_unused_ttbr1_0 = 0, ttbr1_ns = 0, _unused_ttbr1_1 = 0,
        ttbr1_s = 0}, ttbr1_el = {0, 0, 0, 0}}, vttbr_el2 = 0, tcr_el = {{raw_tcr = 0, mask = 0,
        base_mask = 0}, {raw_tcr = 0, mask = 0, base_mask = 4294950912}, {raw_tcr = 0, mask = 0,
        base_mask = 0}, {raw_tcr = 0, mask = 0, base_mask = 0}}, vtcr_el2 = {raw_tcr = 0, mask = 0,
      base_mask = 0}, c2_data = 0, c2_insn = 0, {{dacr_ns = 0, dacr_s = 0}, {dacr32_el2 = 0}},
    pmsav5_data_ap = 0, pmsav5_insn_ap = 0, hcr_el2 = 0, scr_el3 = 0, {{ifsr_ns = 0, ifsr_s = 0}, {
        ifsr32_el2 = 0}}, {{_unused_dfsr = 0, dfsr_ns = 0, hsr = 0, dfsr_s = 0}, esr_el = {0, 0, 0, 0}},
    c6_region = {0, 0, 0, 0, 0, 0, 0, 0}, {{_unused_far0 = 0, dfar_ns = 0, ifar_ns = 0, dfar_s = 0, ifar_s = 0,
        _unused_far3 = 0}, far_el = {0, 0, 0, 0}}, hpfar_el2 = 0, hstr_el2 = 0, {{_unused_par_0 = 0,
        par_ns = 0, _unused_par_1 = 0, par_s = 0}, par_el = {0, 0, 0, 0}}, c9_insn = 0, c9_data = 0,
    c9_pmcr = 1090527296, c9_pmcnten = 0, c9_pmovsr = 0, c9_pmuserenr = 0, c9_pmselr = 0, c9_pminten = 0, {{
        _unused_mair_0 = 0, mair0_ns = 0, mair1_ns = 0, _unused_mair_1 = 0, mair0_s = 0, mair1_s = 0},
      mair_el = {0, 0, 0, 0}}, {{_unused_vbar = 0, vbar_ns = 0, hvbar = 0, vbar_s = 0}, vbar_el = {0, 0, 0,
        0}}, mvbar = 0, {fcseidr_ns = 0, fcseidr_s = 0}, {{_unused_contextidr_0 = 0, contextidr_ns = 0,
        _unused_contextidr_1 = 0, contextidr_s = 0}, contextidr_el = {0, 0, 0, 0}}, {{tpidrurw_ns = 0,
        tpidrprw_ns = 0, htpidr = 0, _tpidr_el3 = 0}, tpidr_el = {0, 0, 0, 0}}, tpidrurw_s = 0, tpidrprw_s = 0,
    tpidruro_s = 0, {tpidruro_ns = 0, tpidrro_el = {0}}, c14_cntfrq = 62500000, c14_cntkctl = 0,
    cnthctl_el2 = 0, cntvoff_el2 = 0, c14_timer = {{cval = 0, ctl = 0}, {cval = 0, ctl = 0}, {cval = 0,
        ctl = 0}, {cval = 0, ctl = 0}, {cval = 0, ctl = 0}}, c15_cpar = 0, c15_ticonfig = 0, c15_i_max = 0,
    c15_i_min = 0, c15_threadid = 0, c15_config_base_address = 0, c15_diagnostic = 0, c15_power_diagnostic = 0,
    c15_power_control = 0, dbgbvr = {0 <repeats 16 times>}, dbgbcr = {0 <repeats 16 times>}, dbgwvr = {
      0 <repeats 16 times>}, dbgwcr = {0 <repeats 16 times>}, mdscr_el1 = 0, oslsr_el1 = 10, mdcr_el2 = 0,
    mdcr_el3 = 0, c15_ccnt = 0, c15_ccnt_delta = 0, c14_pmevcntr = {0 <repeats 31 times>},
    c14_pmevcntr_delta = {0 <repeats 31 times>}, c14_pmevtyper = {0 <repeats 31 times>}, pmccfiltr_el0 = 0,
--Type <RET> for more, q to quit, c to continue without paging--
    vpidr_el2 = 0, vmpidr_el2 = 0, tfsr_el = {0, 0, 0, 0}, gcr_el1 = 0, rgsr_el1 = 0}, v7m = {other_sp = 0,
    other_ss_msp = 0, other_ss_psp = 0, vecbase = {0, 0}, basepri = {0, 0}, control = {0, 0}, ccr = {0, 0},
    cfsr = {0, 0}, hfsr = 0, dfsr = 0, sfsr = 0, mmfar = {0, 0}, bfar = 0, sfar = 0, mpu_ctrl = {0, 0},
    exception = 0, primask = {0, 0}, faultmask = {0, 0}, aircr = 0, secure = 0, csselr = {0, 0}, scr = {0, 0},
    msplim = {0, 0}, psplim = {0, 0}, fpcar = {0, 0}, fpccr = {0, 0}, fpdscr = {0, 0}, cpacr = {0, 0},
    nsacr = 0, ltpsize = 0}, exception = {syndrome = 0, fsr = 0, vaddress = 0, target_el = 0}, serror = {
    pending = 0 '\000', has_esr = 0 '\000', esr = 0}, ext_dabt_raised = 0 '\000', irq_line_state = 0,
  teecr = 0, teehbr = 0, vfp = {zregs = {{d = {0, 0}} <repeats 32 times>}, qc = {0, 0, 0, 0}, vec_len = 0,
    vec_stride = 0, xregs = {1090793712, 0, 0, 0, 0, 67, 320934161, 286327330, 1073741824, 0, 0, 0, 0, 0, 0,
      0}, scratch = {0, 0, 0, 0, 0, 0, 0, 0}, fp_status = {float_rounding_mode = float_round_nearest_even,
      float_exception_flags = 0 '\000', floatx80_rounding_precision = 0 '\000',
      tininess_before_rounding = true, flush_to_zero = false, flush_inputs_to_zero = false,
      default_nan_mode = false, snan_bit_is_one = false, use_first_nan = false, no_signaling_nans = false},
    fp_status_f16 = {float_rounding_mode = float_round_nearest_even, float_exception_flags = 0 '\000',
      floatx80_rounding_precision = 0 '\000', tininess_before_rounding = true, flush_to_zero = false,
      flush_inputs_to_zero = false, default_nan_mode = false, snan_bit_is_one = false, use_first_nan = false,
      no_signaling_nans = false}, standard_fp_status = {float_rounding_mode = float_round_nearest_even,
      float_exception_flags = 0 '\000', floatx80_rounding_precision = 0 '\000',
      tininess_before_rounding = true, flush_to_zero = true, flush_inputs_to_zero = true,
      default_nan_mode = true, snan_bit_is_one = false, use_first_nan = false, no_signaling_nans = false},
    standard_fp_status_f16 = {float_rounding_mode = float_round_nearest_even, float_exception_flags = 0 '\000',
      floatx80_rounding_precision = 0 '\000', tininess_before_rounding = true, flush_to_zero = false,
      flush_inputs_to_zero = false, default_nan_mode = true, snan_bit_is_one = false, use_first_nan = false,
      no_signaling_nans = false}, zcr_el = {0, 0, 0, 0}}, exclusive_addr = 0, exclusive_val = 0,
  exclusive_high = 0, iwmmxt = {regs = {0 <repeats 16 times>}, val = 0, cregs = {0 <repeats 16 times>}},
  eabi = 0, cpu_breakpoint = {0x0 <repeats 16 times>}, cpu_watchpoint = {0x0 <repeats 16 times>},
  end_reset_fields = {<No data fields>}, features = 30989547897, pmsav7 = {drbar = 0x0, drsr = 0x0,
    dracr = 0x0, rnr = {0, 0}}, pmsav8 = {rbar = {0x0, 0x0}, rlar = {0x0, 0x0}, mair0 = {0, 0}, mair1 = {0,
      0}}, sau = {rbar = 0x0, rlar = 0x0, rnr = 0, ctrl = 0}, nvic = 0x0, boot_info = 0x0, gicv3state = 0x0}

At this point you’d have to know about the internals of qemu…


Other approach: check how it goes there. Perhaps something about the
ELF headers of klibc*.so and/or fstype…

bye,
//mirabilos
-- 
<igli> exceptions: a truly awful implementation of quite a nice idea.
<igli> just about the worst way you could do something like that, afaic.
<igli> it's like anti-design.  <mirabilos> that too… may I quote you on that?
<igli> sure, tho i doubt anyone will listen ;)

[toc] | [prev] | [next] | [standalone]

#1154134 — Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

On 7/14/23 01:56, Thorsten Glaser wrote:
> Dixi quod…
>
>> My guess here is that it’s, as usual, the fault of qemu-user,
>
> Strong evidence for that: doesn’t look like it even executes
> one bit of klibc code:
>
> $ qemu-arm-static -d cpu ./fstype --help
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault (core dumped)

what does this show?:
QEMU_STRACE=1 qemu-arm-static -d cpu ./fstype --help

I still believe, that the problem is that qemu's brk(NULL) doesn't return
a page-aligned address, which will have lots of other side-effects.
(see Andreas' RISC-V crash here: https://lists.nongnu.org/archive/html/qemu-devel/2023-07/msg00645.html)

Helge

[toc] | [prev] | [next] | [standalone]

#1154181

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2023-07-13 at 22:27 +0000, Thorsten Glaser wrote:
> retitle 1040981 klibc-utils: segfault executing armhf binaries under qemu-user
> thanks
> 
> Venkata.Pyla@toshiba-tsip.com dixit:
> 
> > Follow below steps to reproduce this issue
> > ```
> > $ sudo debootstrap --arch=arm bookworm arm-bookworm-rootfs/ http://deb.debian.org/debian/
> > $ sudo chroot arm-bookworm/ apt-update && apt install -y klibc-utils
> > $ sudo chroot arm-bookworm/ /usr/lib/klibc/bin/fstype --help
> > qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> > Segmentation fault
> > ```
> 
> Same when just copying klibc-m13AniKHUCMUNN8mXSUhIi8CUSA.so out
> of libklibc_2.0.12-1_armhf.deb into /lib/ and extracting fstype
> from klibc-utils_2.0.12-1_armhf.deb… however it works both on a
> real-metal ARM box (amdahl.d.o) and a statically(!) linked mksh
> against klibc :/
> 
> My guess here is that it’s, as usual, the fault of qemu-user,
> which has multiple outstanding emulation bugs, some of which
> affecting klibc-built binaries especially, though this, since
> a statically linked mksh works, is probably an issue with how
> qemu-user handles .interp *shrug*
[...]

I use QEMU to test klibc changes on as many architectures as possible.
For a long time I used QEMU 3.1 with some cherry-picked bug fixes.  
All the GNU-built binaries would run successfully on that, but Clang-
built binaries for some architectures did not.

Switching klibc to the time64 kernel API forced me to update to QEMU
7.2.  This introduced regressions for shared-library executables for
armhf and riscv64.

There is some more detail on this at
<https://git.kernel.org/pub/scm/linux/kernel/git/bwh/klibc-maint.git/plain/status.md>

Ben.

-- 
Ben Hutchings
Hoare's Law of Large Problems:
   Inside every large problem is a small problem struggling to get out.

[toc] | [prev] | [next] | [standalone]

#1154184

14.07.2023 16:18, Ben Hutchings wrote:
..
> I use QEMU to test klibc changes on as many architectures as possible.
> For a long time I used QEMU 3.1 with some cherry-picked bug fixes.
> All the GNU-built binaries would run successfully on that, but Clang-
> built binaries for some architectures did not.
> 
> Switching klibc to the time64 kernel API forced me to update to QEMU
> 7.2.  This introduced regressions for shared-library executables for
> armhf and riscv64.

that's definitely not good. The problem here seems to be that apparently
no one knows about these problems, so no one can fix them either.

For the very least, - since I know very little about actual emulation
internals myself, - maybe there's a way to bisect things?  Some simple
reproducer for the segfault, which don't use 64bit time_t so can run
on qemu 3.1 and 7.2?

Ben, I'd really love to have the bugs fixed. But I need some of your
knowledge for that too ;)

Thanks!

/mjt

[toc] | [prev] | [next] | [standalone]

#1154240 — Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

Ben Hutchings dixit:

>7.2.  This introduced regressions for shared-library executables for

I did notice the following:


amd64:

/lib/klibc-YUkGbOClhnaZRUUd4cUed0X2XZI.so:     file format elf64-x86-64
/lib/klibc-YUkGbOClhnaZRUUd4cUed0X2XZI.so
architecture: i386:x86-64, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x0000000000201034

Program Header:
    LOAD off    0x0000000000000000 vaddr 0x0000000000200000 paddr 0x0000000000200000 align 2**12
         filesz 0x00000000000001b4 memsz 0x00000000000001b4 flags r--
    LOAD off    0x0000000000001000 vaddr 0x0000000000201000 paddr 0x0000000000201000 align 2**12
         filesz 0x000000000000cf07 memsz 0x000000000000cf07 flags r-x
    LOAD off    0x000000000000e000 vaddr 0x000000000020e000 paddr 0x000000000020e000 align 2**12
         filesz 0x0000000000003f6f memsz 0x0000000000003f6f flags r--
    LOAD off    0x0000000000012000 vaddr 0x0000000000212000 paddr 0x0000000000212000 align 2**12
         filesz 0x0000000000000140 memsz 0x0000000000004438 flags rw-
    NOTE off    0x0000000000000190 vaddr 0x0000000000200190 paddr 0x0000000000200190 align 2**2
         filesz 0x0000000000000024 memsz 0x0000000000000024 flags r--
   STACK off    0x0000000000000000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**4
         filesz 0x0000000000000000 memsz 0x0000000000000000 flags rwx

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .note.gnu.build-id 00000024  0000000000200190  0000000000200190  00000190  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text         0000cf07  0000000000201000  0000000000201000  00001000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
[…]
Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  LOAD           0x000000 0x0000000000200000 0x0000000000200000 0x0001b4 0x0001b4 R   0x1000
  LOAD           0x001000 0x0000000000201000 0x0000000000201000 0x00cf07 0x00cf07 R E 0x1000
  LOAD           0x00e000 0x000000000020e000 0x000000000020e000 0x003f6f 0x003f6f R   0x1000
  LOAD           0x012000 0x0000000000212000 0x0000000000212000 0x000140 0x004438 RW  0x1000
  NOTE           0x000190 0x0000000000200190 0x0000000000200190 0x000024 0x000024 R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x10

 Section to Segment mapping:
  Segment Sections...
   00     .note.gnu.build-id
   01     .text
   02     .rodata
   03     .data .bss
   04     .note.gnu.build-id


armhf:

/lib/klibc-m13AniKHUCMUNN8mXSUhIi8CUSA.so:     file format elf32-littlearm
/lib/klibc-m13AniKHUCMUNN8mXSUhIi8CUSA.so
architecture: armv7, flags 0x00000102:
EXEC_P, D_PAGED
start address 0x003800f9

Program Header:
    LOAD off    0x00000000 vaddr 0x00380000 paddr 0x00380000 align 2**12
         filesz 0x0000cecf memsz 0x0000cecf flags r-x
    LOAD off    0x0000d000 vaddr 0x0038d000 paddr 0x0038d000 align 2**12
         filesz 0x000000b8 memsz 0x00002254 flags rw-
    NOTE off    0x000000b4 vaddr 0x003800b4 paddr 0x003800b4 align 2**2
         filesz 0x00000024 memsz 0x00000024 flags r--
   STACK off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**4
         filesz 0x00000000 memsz 0x00000000 flags rw-
private flags = 5000400: [Version5 EABI] [hard-float ABI]

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .note.gnu.build-id 00000024  003800b4  003800b4  000000b4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text         00009974  003800d8  003800d8  000000d8  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
[…]
Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00380000 0x00380000 0x0cecf 0x0cecf R E 0x1000
  LOAD           0x00d000 0x0038d000 0x0038d000 0x000b8 0x02254 RW  0x1000
  NOTE           0x0000b4 0x003800b4 0x003800b4 0x00024 0x00024 R   0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x10

 Section to Segment mapping:
  Segment Sections...
   00     .note.gnu.build-id .text .rodata
   01     .data .bss
   02     .note.gnu.build-id


Specifically, what I noted is that, on amd64, the .text section
inside the text segment, which here isn’t shared with the buildid
section, has a page align increment from .note.gnu.build-id but
the armhf one doesn’t.

So I added -Ttext 0x381000 to the link command, to get…

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         0000997c  00381000  00381000  00001000  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .note.gnu.build-id 00000024  003800b4  003800b4  000000b4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
[…]

… but the segfault persists, so maybe that’s not it, or that’s
not yet enough and we have to use a linker script to put the
buildid section inside its own segment like it does on amd64.

The failing offset is 0x3800F8, which is a couple of bytes into
.text, after all.

But /proc/27269/maps for the qemu process (with a user memory
base of 0x40D94000 so the failing address is 0x411140F8, this
isn’t reflected…

40da6000-80d94000 ---p 00000000 00:00 0

… in contrast to lower user memory, which has…

40da4000-40da5000 r--p 00000000 fd:00 2234167                            /home/tglase/fstype
40da5000-40da6000 rw-p 00000000 fd:00 2234167                            /home/tglase/fstype

… the fstype binary mapped. So maybe qemu fails totally to load
and/or map the interpreter 🙀


I think pretty much *any* dynamically-linked klibc binary should
fail with that, right now, independent of what features it uses
or something, as the code isn’t even reached.

And, indeed, the combination of klibc-sKNr1Fw-Rh9G1FYpGCXRnrwmP2A.so
and fstype from 2.0.4-2 (jessie) also fails, so you have something
that can reliably be used in bisect tests I think.


Good luck,
//mirabilos
-- 
<ch> you introduced a merge commit        │<mika> % g rebase -i HEAD^^
<mika> sorry, no idea and rebasing just fscked │<mika> Segmentation
<ch> should have cloned into a clean repo      │  fault (core dumped)
<ch> if I rebase that now, it's really ugh     │<mika:#grml> wuahhhhhh

[toc] | [prev] | [next] | [standalone]

#1154248 — Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

14.07.2023 21:34, Thorsten Glaser wrote:
..

> And, indeed, the combination of klibc-sKNr1Fw-Rh9G1FYpGCXRnrwmP2A.so
> and fstype from 2.0.4-2 (jessie) also fails, so you have something
> that can reliably be used in bisect tests I think.

Ok, this works.  The bisection points to this commit between qemu v4.2.0
and v5.0.0:

https://gitlab.com/qemu-project/qemu/-/commit/6fd5944980f4ccee728ce34bdaffc117db50b34d

commit 6fd5944980f4ccee728ce34bdaffc117db50b34d
Author: Richard Henderson <richard.henderson@linaro.org>
Date:   Fri Jan 17 13:02:45 2020 -1000

     linux-user: Reserve space for brk

     With bad luck, we can wind up with no space at all for brk,
     which will generally cause the guest malloc to fail.

     This bad luck is easier to come by with ET_DYN (PIE) binaries,
     where either the stack or the interpreter (ld.so) gets placed
     immediately after the main executable.

     But there's nothing preventing this same thing from happening
     with ET_EXEC (normal) binaries, during probe_guest_base().

     In both cases, reserve some extra space via mmap and release
     it back to the system after loading the interpreter and
     allocating the stack.

     The choice of 16MB is somewhat arbitrary.  It's enough for libc
     to get going, but without being so large that 32-bit guests or
     32-bit hosts are in danger of running out of virtual address space.
     It is expected that libc will be able to fall back to mmap arenas
     after the limited brk space is exhausted.

     Launchpad: https://bugs.launchpad.net/qemu/+bug/1749393
     Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
     Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
     Tested-by: Alex Bennée <alex.bennee@linaro.org>
     Message-Id: <20200117230245.5040-1-richard.henderson@linaro.org>
     Signed-off-by: Laurent Vivier <laurent@vivier.eu>


Does this ring any bells?  Verified on armhf.
I'll bug upstream.

Thanks,

/mjt

[toc] | [prev] | [next] | [standalone]

#1154250 — Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

Michael Tokarev dixit:

> commit 6fd5944980f4ccee728ce34bdaffc117db50b34d

From the comment, it reserves 16 MiB after the main executable.

In klibc/armhf, however, the main executable starts around
0x00010000 whereas the interpreter starts after that, around
0x00380000…

Perhaps the fix here would be to see if the interpreter comes
within 16 MiB past the main executable’s end, and if so, to
move the break (I wasn’t aware stuff on GNU/Linux still uses
that!) to start after the interpreter instead.

The BSD manpage begins with…
DESCRIPTION
     The brk() and sbrk() functions are historical curiosities left over from
     earlier days before the advent of virtual memory management.
… so… oh well.

Anyway, while my proposed fix in theory moves the “end of the
process’ data segment” to behind the interpreter instead of
behind the main executable, processes are not supposed to use
it in combination with _end, only the returned pointers. It’s
something to at least consider. Will you forward this upstream?


Given how this both constraints executables’ sizes and perhaps
has effects on other loaders, perhaps the klibc upstream could
consider switching to using linker scripts or at least move the
respective text basēs, on all architectures, so that the main
executable comes after the interpreter.

This will of course not help bookworm users but, perhaps, it is
something, again, to consider, at least.


bye,
//mirabilos
-- 
This space for rent.

https://paypal.me/mirabilos to support my work.

[toc] | [prev] | [next] | [standalone]

#1154251 — Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

Control: forwarded -1 https://lists.nongnu.org/archive/html/qemu-devel/2023-07/msg03138.html

14.07.2023 23:07, Thorsten Glaser wrote:
> Michael Tokarev dixit:
> 
>> commit 6fd5944980f4ccee728ce34bdaffc117db50b34d
> 
>  From the comment, it reserves 16 MiB after the main executable.
> 
> In klibc/armhf, however, the main executable starts around
> 0x00010000 whereas the interpreter starts after that, around
> 0x00380000…

Aren't it happens on all architectures, not just armhf?
I had an impression it is not arch-specific. $subject
mentions armhf only, but I think somewhere in the discussion
it's been said all architectures are affected?  Ok.

> Perhaps the fix here would be to see if the interpreter comes
> within 16 MiB past the main executable’s end, and if so, to
> move the break (I wasn’t aware stuff on GNU/Linux still uses
> that!) to start after the interpreter instead.
> 
> The BSD manpage begins with…
> DESCRIPTION
>       The brk() and sbrk() functions are historical curiosities left over from
>       earlier days before the advent of virtual memory management.
> … so… oh well.

That's lovely.  There's another change for brk() pending in qemu right
now (to make it page-aligned; and no, it does not fix this issue).
I guess it is not just curiocities :)

> Anyway, while my proposed fix in theory moves the “end of the
> process’ data segment” to behind the interpreter instead of
> behind the main executable, processes are not supposed to use
> it in combination with _end, only the returned pointers. It’s
> something to at least consider. Will you forward this upstream?

Yeah, already did, was just waiting for it to appear in the archives
for the URL.

Thank you!

/mjt

[toc] | [prev] | [next] | [standalone]

#1154280 — Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

Michael Tokarev dixit:

>>
>> From the comment, it reserves 16 MiB after the main executable.
>>
>> In klibc/armhf, however, the main executable starts around
>> 0x00010000 whereas the interpreter starts after that, around
>> 0x00380000…
>
> Aren't it happens on all architectures, not just armhf?

bullseye/amd64:

0x00200000 interp
0x00400000 main executable

So no, this applies only to some architectures, but not because…

> I had an impression it is not arch-specific. $subject

… it’s arch-specific but because klibc memory map is, so the
effect only occurs on those arches where klibc puts the interp
before the main executable.

This is unfortunately hard to grep for, because…

usr/klibc/arch/arm/MCONFIG:KLIBCSHAREDFLAGS = $(LD_IMAGE_BASE_OPT) 0x380000

… this applies to the interp, but for the main executables
it uses the linker’s default AFAICT.

There is…

usr/klibc/arch/arm64/MCONFIG:KLIBCLDFLAGS  = $(LD_IMAGE_BASE_OPT) 0x00400000
usr/klibc/arch/arm64/MCONFIG:KLIBCSHAREDFLAGS = $(LD_IMAGE_BASE_OPT) 0x0200000

… which does transfer to main at 00400000 interp at 00200000 respectively,
but only arm64 and “x32”, which really builds as amd64, do that.

And Itanic uses a linker script, putting the interp at
0x2000000000000000 (which seems to be standard for ia64).
0x40000000000001c8 is the beginning of the main executable
there, from analysing the built binaries.

It would be more robust if klibc always specified both.

But, as I said earlier, this won’t help bookworm and earlier
so fixing this in qemu is appreciated ;-)

>> The BSD manpage begins with…
>> DESCRIPTION
>>      The brk() and sbrk() functions are historical curiosities left over from
>>      earlier days before the advent of virtual memory management.
>> … so… oh well.
>
> That's lovely.  There's another change for brk() pending in qemu right
> now (to make it page-aligned; and no, it does not fix this issue).
> I guess it is not just curiocities :)

Perhaps. In the BSD world, malloc has been always using mmap for
ages, especially as the kernel randomises anon mmap addresses.

>> Anyway, while my proposed fix in theory moves the “end of the
>> process’ data segment” to behind the interpreter instead of
>> behind the main executable, processes are not supposed to use
>> it in combination with _end, only the returned pointers. It’s
>> something to at least consider. Will you forward this upstream?
>
> Yeah, already did, was just waiting for it to appear in the archives
> for the URL.

I meant the suggested fix. I’m not sure people over there will
dig through all of the analysis and discussion here… but maybe
a tl;dr could be posted there as well?

Thanks,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
	-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

[toc] | [prev] | [next] | [standalone]

#1154438 — Bug#1040981: klibc-utils: segfault executing armhf binaries under qemu-user

[Multipart message — attachments visible in raw view] — view raw

On Fri, 2023-07-14 at 22:08 +0000, Thorsten Glaser wrote:
> Michael Tokarev dixit:
> 
> > > 
> > > From the comment, it reserves 16 MiB after the main executable.
> > > 
> > > In klibc/armhf, however, the main executable starts around
> > > 0x00010000 whereas the interpreter starts after that, around
> > > 0x00380000…
> > 
> > Aren't it happens on all architectures, not just armhf?
> 
> bullseye/amd64:
> 
> 0x00200000 interp
> 0x00400000 main executable
> 
> So no, this applies only to some architectures, but not because…
> 
> > I had an impression it is not arch-specific. $subject
> 
> … it’s arch-specific but because klibc memory map is, so the
> effect only occurs on those arches where klibc puts the interp
> before the main executable.

You mean after, but it's more specific than that in practice.

> This is unfortunately hard to grep for, because…
> 
> usr/klibc/arch/arm/MCONFIG:KLIBCSHAREDFLAGS = $(LD_IMAGE_BASE_OPT) 0x380000
> 
> … this applies to the interp, but for the main executables
> it uses the linker’s default AFAICT.
> 
> There is…
> 
> usr/klibc/arch/arm64/MCONFIG:KLIBCLDFLAGS  = $(LD_IMAGE_BASE_OPT) 0x00400000
> usr/klibc/arch/arm64/MCONFIG:KLIBCSHAREDFLAGS = $(LD_IMAGE_BASE_OPT) 0x0200000
> 
> … which does transfer to main at 00400000 interp at 00200000 respectively,
> but only arm64 and “x32”, which really builds as amd64, do that.
> 
> And Itanic uses a linker script, putting the interp at
> 0x2000000000000000 (which seems to be standard for ia64).
> 0x40000000000001c8 is the beginning of the main executable
> there, from analysing the built binaries.
> 
> It would be more robust if klibc always specified both.
[...]

It would be a little more robust, and certainly easier to understand.

Here's what we have now:

Architecture  klibc base (hex)  Exec base (hex)     Offset (MiB)
---------------------------------------------------------------------
alpha                1_c0000000        1_20000000*             -2_560
arm [THUMB=y]            380000             10000**                -3
arm [THUMB=n]           1800000             10000**               -24
arm64                    200000            400000                   2
i386                    6000000           8000000*                 32
ia64          20000000_00000000 40000000_00000000** 2_199_023_255_552
loongarch64          1_27E00000        1_20000000*               -126
m68k                   b0000000          80000000*               -768
mips                     200000            400000*                  2
mips64               1_2FE00000        1_20000000*               -254
parisc                 40001000             10000**            -1_024
ppc                     f800000          10000000*                  8
ppc64                   f000000          10000000*                 16
riscv64                  200000             10000*                 -2
s390                   40000000            400000**            -1_020
s390x                  40000000           1000000**            -1_008
sh                       200000            400000*                  2
sparc                  40000000             10000*             -1_024
sparc64                80000000            100000*             -2_047
x86_64                   200000            400000                   2

* Assumption commented in MCONFIG.
** Observed with objdump.

In 12 cases (a majority), the offset between klibc.so and the
executable is negative.  However, only riscv64 and arm with THUMB=y
have such small negative offsets (-2 and -3.4375 MiB respectively)
which I suppose puts them more at risk from this bug.

The Debian package is built with THUMB=y for armhf but not armel, which
seems like a mistake because the Arm EABI requires Thumb support.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
                                                       - Robert Coveyou

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web