NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: port-amd64/51700: exect(NULL,NULL,NULL) generates 15859 times SIGTRAP on amd64

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

From: Kamil Rytarowski <>
Subject: Re: port-amd64/51700: exect(NULL,NULL,NULL) generates 15859 times
 SIGTRAP on amd64
Date: Fri, 9 Dec 2016 10:47:52 +0100

 This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
 Content-Type: multipart/mixed; boundary="kwFMJQnhwOSeUsptJJ1MMGmLvXhLtXrTK"
 From: Kamil Rytarowski <>
 Message-ID: <>
 Subject: Re: port-amd64/51700: exect(NULL,NULL,NULL) generates 15859 times
  SIGTRAP on amd64
 References: <>
 In-Reply-To: <>
 Content-Type: text/plain; charset=windows-1252
 Content-Transfer-Encoding: quoted-printable
 Since this interface is apparently unclear I will add few sentences.
 The exect(3) call is an extension to execve(2),  it's added
 functionality is to raise SIGTRAP with si_code TRAP_TRACE.
 Currently mainly vax, i386 and amd64 implement this interface through
 libc, however with this is more a hack, as these port set machine flag
 used to step the code and resumes with execve(2).
 If we want to keep its implementation in libc I think the best solution
 is to switch this code to the sequence of raise(3) && execve(2) for all
 ports (how to set si_code to TRAP_TRACE in this case?).
 However I think it's little point to trace libc's internals and it might
 be more useful to raise signal just before executing the first
 instruction and this is doable
 The exect(3) function was added on day0 (inherited from 386bsd) and
 perhaps unused since then. The man-page describes it as follows (text
 unmodified since that time):
   The function exect() executes a file with the program tracing
   facilities enabled (see ptrace(2)).
 This sounds to me like exect(3) should be equivalent to PT_TRACE_ME &
 execve(2) & raise(SIGTRAP with si_code=3DTRAP_TRACE) on first instruction=
 of the new image.
 This call is currently unimplemented port-wide and perhaps not really
 functional with ports that implement it either, if we want to fix it I
 think we are free to alter its meaning and make it more useful now.
 I checked 386bsd sources and it's the same as the current i386 version
 -- without particular users. I think the proposed scenario with
 PT_TRACE_ME is the only variation that might be useful.
 exect(3) is kept in FreeBSD with the original questionable behavior and
 absent in OpenBSD
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: OpenPGP digital signature
 Content-Disposition: attachment; filename="signature.asc"
 Version: GnuPG v2

Home | Main Index | Thread Index | Old Index