Re: port-hppa/56867: hppa: intermittent SIGSEGV reports in t_ptrace_wait's stepN and setstepN test cases

[Tom Lane <tgl%sss.pgh.pa.us@localhost>]

The following reply was made to PR port-hppa/56867; it has been noted by GNATS.

From: Tom Lane <tgl%sss.pgh.pa.us@localhost>
To: Nick Hudson <nick.hudson%gmx.co.uk@localhost>
Cc: gnats-bugs%netbsd.org@localhost, port-hppa-maintainer%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
Subject: Re: port-hppa/56867: hppa: intermittent SIGSEGV reports in t_ptrace_wait's stepN and setstepN test cases
Date: Fri, 10 Jun 2022 07:49:21 -0400

 Nick Hudson <nick.hudson%gmx.co.uk@localhost> writes:
 > On 09/06/2022 06:40, Tom Lane wrote:
 >> ... I found that the test passes when an ITLBMISS trap
 >> occurs upon trying to execute the modified instruction stream, while
 >> it fails when one does not.  That led me to guess that what's missing
 >> is a TLB flush operation, and sure enough this quick-hack patch seems
 >> to fix it:
 
 > I dont this is right. The process mappings aren't changing. Will think
 > about it some more.
 
 Fair enough.  One thing worth noting is that the place where the
 breakpoint instructions are being dropped is inside libc (in
 _lwp_kill, where the tracee process self-SIGSTOP'd).  I have not
 been able to figure out how it's okay at all to be modifying libc.
 I guess that there's a copy-on-write happening somewhere so that
 the traced process gets its own copy of this shared page, but
 I couldn't find where that happens.  If there isn't a copy, maybe
 that is a bug in itself?  If there is a copy, then the process
 mapping *is* changing, although you'd think the COW code would
 have dealt with it.
 
 			regards, tom lane