05.08.2023 01:00, Richard Henderson wrpte:
> Supercedes: 20230804014517.6361-1-richard.henderson@linaro.org
> ("[PATCH for-8.1 v8 00/17] linux-user: brk fixes")
>
> Changes for linux-user brk v9:
> Recover some changes that should have been in v8, had I
> generated the patches from the correct tree:
> - bsd-user: Remove last_brk
> - Fix typos in patch 15 ("Define ELF_ET_DYN_BASE...")
> - Disable -Werror=type-limits in patch 13
> ("linux-user: Adjust task_unmapped_base")
FWIW.
qemu-8.1 rc, with or without this patch set, does not work in
old aarch64 environment at all. F.e. ubuntu xenial or debian
jessie, like this:
# chroot /tmp/jessie-arm64/
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
dash works, but bash or ls gives such sigsegv.
$ gdb qemu-aarch64 /tmp/jessie-arm64/core
GNU gdb (Debian 13.1-3) 13.1
...
[New LWP 2021520]
[New LWP 2021522]
warning: Section `.reg-xstate/2021520' in core file too small.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/tmp/qemu-aarch64 /bin/ls'.
Program terminated with signal SIGSEGV, Segmentation fault.
warning: Section `.reg-xstate/2021520' in core file too small.
#0 0x00007fa931538c31 in sigsuspend ()
[Current thread is 1 (Thread 0x5555573144c0 (LWP 2021520))]
warning: File "/build/qemu/test/.gdbinit" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /build/qemu/test/.gdbinit
line to your configuration file "/home/mjt/.config/gdb/gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/mjt/.config/gdb/gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
(gdb) bt
#0 0x00007fa931538c31 in sigsuspend ()
#1 0x00007fa93136f670 in dump_core_and_abort (cpu_env=cpu_env@entry=0x555557328800, target_sig=target_sig@entry=11) at ../linux-user/signal.c:747
#2 0x00007fa93136f9f5 in handle_pending_signal (cpu_env=0x555557328800, sig=11, k=0x555557390d80) at ../linux-user/signal.c:1068
#3 0x00007fa9313716b5 in process_pending_signals (cpu_env=cpu_env@entry=0x555557328800) at ../linux-user/signal.c:1143
#4 0x00007fa93118f09a in cpu_loop (env=env@entry=0x555557328800) at ../linux-user/aarch64/cpu_loop.c:179
#5 0x00007fa93118a498 in main (argc=<optimized out>, argv=0x7ffea05e15d8, envp=<optimized out>) at ../linux-user/main.c:1014
(gdb) frame 2
#2 0x00007fa93136f9f5 in handle_pending_signal (cpu_env=0x555557328800, sig=11, k=0x555557390d80) at ../linux-user/signal.c:1068
1068 dump_core_and_abort(cpu_env, sig);
(gdb) frame 3
#3 0x00007fa9313716b5 in process_pending_signals (cpu_env=cpu_env@entry=0x555557328800) at ../linux-user/signal.c:1143
1143 handle_pending_signal(cpu_env, sig, &ts->sync_signal);
(gdb) l
1138 || sigact_table[sig - 1]._sa_handler == TARGET_SIG_IGN) {
1139 sigdelset(&ts->signal_mask, target_to_host_signal_table[sig]);
1140 sigact_table[sig - 1]._sa_handler = TARGET_SIG_DFL;
1141 }
1142
1143 handle_pending_signal(cpu_env, sig, &ts->sync_signal);
1144 }
1145
1146 for (sig = 1; sig <= TARGET_NSIG; sig++) {
1147 blocked_set = ts->in_sigsuspend ?
(gdb)
Is it worth to bisect?
/mjt