Date: Thu, 25 Sep 2025 22:38:35 +0200 From: Paul Floyd <paulf2718@gmail.com> To: Freebsd hackers list <freebsd-hackers@FreeBSD.org> Subject: Re: ptrace PT_SETREGS issue Message-ID: <B2863AFB-DAAB-4F56-8DB5-84E4B21D4BE5@gmail.com> In-Reply-To: <6e71483f-e0af-4933-b200-55e660b5748d@gmail.com> References: <6e71483f-e0af-4933-b200-55e660b5748d@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 22 Sep 2025, at 13:39, Paul Floyd <paulf2718@gmail.com> wrote:
>
> Hi
>
> The second issue that I'm seeing with FreeBSD 15 is with ALPHA2 on aarch64.
>
> The problem is with ptrace PT_SETREGS.
>
> The context is when Valgrind is running with a connection to vgdb/gdb. In this configuration, if the user wants to interrupt the running process with control C the following sequence of events happens
>
> 1. vgdb uses ptrace to attach to the Valgrind process
>
> 2. It brute-force modifies the PC so that Valgrind will execute a function that will interrupt the guest process.
>
> This has been working for a bit over a year since aarch64 support in Valgrind was added. With FreeBSD there is an issue. As an additional check the ptrace code writes a special value, 0x8BADF00D in x0 (first function call argument). On the receiving end there's an assert. That assert is now firing (I'm seeing a value of 4 in the first argument). If I uncomment the assert then the tests all work. That means that PC is getting set OK but not X0.
>
> The code that does this is
>
> static
> Bool setregs (pid_t pid, struct reg *regs)
> {
> if (ptrace(PT_SETREGS, pid, (caddr_t)regs, 0) < 0) {
> return False;
> }
> return True;
> }
>
I did some more work on this. I added a check with ptrace PT_GETREGS and then did a memcmp of the two and they are the same.
So it looks like vgdb and ptrace both think everything is OK.
Now I have to see how I can debug Valgrind from the moment the vgdb does a ptrace detach of its process.
A+
Paul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B2863AFB-DAAB-4F56-8DB5-84E4B21D4BE5>