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: [email protected]
Reporter: [email protected]
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.
