Date: Sun, 05 Oct 2025 06:37:37 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 290008] 15.0-ALPHA4 aarch64: ptrace PT_SETREGS issue Message-ID: <bug-290008-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290008 Bug ID: 290008 Summary: 15.0-ALPHA4 aarch64: ptrace PT_SETREGS issue Product: Base System Version: 15.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: pjfloyd@wanadoo.fr I'm having an issue with ptrace PT_SETREGS on FreeBSD 15.0-ALPHA4 (and ALPHA3) on aarch64. I don't know exactly when this started since I don't regularly update my CURRENT VMs. This seems to be a regression related to FreeBSD 15. It worked OK with FreeBSD 14.0 14.1 and works OK with 14.3. What should happen. ------------------- The purpose of the code is to force a call to a polling function if the inferior is blocked in system calls. 1. Call ptrace PT_GETREGS to get the stack pointer 2. Set the registers for the polling function a) ELR the address of the polling function b) LR a phony address (0 - the polling function will return via longjmp()) c) SP based on what we got with PT_GETREGS d) X0 argument to the polling function, a check value of 0x8BADF00D e) Call ptrace PT_CONTINUE What is happening ----------------- All the above works OK apart from X0. Instead of seeing 0x8BADF00D the value is 4 which triggers an assert. How to reproduce ---------------- On FreeBSD 15.0-ALPAH4 arm64. You'll need gmake, gdb and autotools installed. glt clone https://sourceware.org/git/valgrind.git cd valgrind ./autogen.sh ./configure gmake make sure that you have two terminals In terminal 1 in the valgrind directory run ./vg-in-place --tool=none --vgdb-eror=0 sleep 10000 In terminal 2 run gdb then at the gdb prompt - replace {path} with the path containing the valgrind directory target remote | {path}/valgrind/coregrind/vgdb then continue then ctrl-c You should get the following (possibly with slightly different line numbers): valgrind: m_gdbserver/m_gdbserver.c:883 (void vgPlain_invoke_gdbserver(int, int)): Assertion 'check == 0x8BADF00D' failed. host stacktrace: ==2874== at 0x380A902C: show_sched_status_wrk (m_libcassert.c:426) ==2874== by 0x380A9353: report_and_quit (m_libcassert.c:497) ==2874== by 0x380A932F: vgPlain_assert_fail (m_libcassert.c:564) ==2874== by 0x38180CB3: vgPlain_invoke_gdbserver (m_gdbserver.c:883) ==2874== by 0xFFFFFFFFFFFFFFFF: ??? sched status: running_tid=0 Thread 1: status = VgTs_WaitSys syscall 240 (lwpid 100170) ==2874== at 0x4D27BF4: _nanosleep (in /lib/libsys.so.7) ==2874== by 0x4010ECF: ??? (in /bin/sleep) ==2874== by 0x49718BB: __libc_start1 (in /lib/libc.so.7) ==2874== by 0x4010C9B: ??? (in /bin/sleep) client stack range: [0x1FBFFFC000 0x1FC0000FFF] client SP: 0x1FC00009A0 valgrind stack range: [0x100278E000 0x100288DFFF] top usage: 12688 of 1048576 I've already tried quite a few things 1. Reading back the registers, they are identical. 2 Reading the instructions from the address put in ELR they match what I see in the binary with objdump. 3. Adding a second argument works OK. The value that I put in X1 appears as the second argument. 4. Tried using clang 19 on FreeBSD 14.3 (19 is the default compiler on FreeBSD 15), and it worked OK. I've looked a bit at the FreeBSD kernel code. I don't really know my way around, but nothing struck me as a possible cause. I'll see if I can produce a smaller reproducer. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-290008-227>