NetBSD Problem Report #51700
From www@NetBSD.org Fri Dec 9 06:37:19 2016
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
by mollari.NetBSD.org (Postfix) with ESMTPS id C40A97A2AD
for <gnats-bugs@gnats.NetBSD.org>; Fri, 9 Dec 2016 06:37:19 +0000 (UTC)
Message-Id: <20161209063718.626CA7A364@mollari.NetBSD.org>
Date: Fri, 9 Dec 2016 06:37:18 +0000 (UTC)
From: n54@gmx.com
Reply-To: n54@gmx.com
To: gnats-bugs@NetBSD.org
Subject: exect(NULL,NULL,NULL) generates 15859 times SIGTRAP on amd64
X-Send-Pr-Version: www-1.0
>Number: 51700
>Category: kern
>Synopsis: exect(NULL,NULL,NULL) generates 15859 times SIGTRAP on amd64
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Dec 09 06:40:00 +0000 2016
>Closed-Date: Mon Jun 04 09:46:04 +0000 2018
>Last-Modified: Mon Jun 04 09:46:04 +0000 2018
>Originator: Kamil Rytarowski
>Release: NetBSD 7.99.42 amd64
>Organization:
TNF
>Environment:
NetBSD chieftec 7.99.42 NetBSD 7.99.42 (GENERIC) #4: Sun Nov 27 14:13:23 CET 2016 root@chieftec:/public/netbsd-tmp-root/sys/arch/amd64/compile/GENERIC amd64
>Description:
exect(2) generates 15859 (in reality any big random number) times SIGTRAP while the same program generates single SIGTRAP.
Other ports are untested.
>How-To-Repeat:
$ cat exect.c
#include <unistd.h>
#include <stdio.h>
#include <errno.h>
#include <assert.h>
#include <signal.h>
#define ATF_REQUIRE(a) assert(a)
#define ATF_REQUIRE_EQ(a,b) assert(a == b)
#define ATF_REQUIRE_ERRNO(a,b) do{assert(errno==a); assert(b);}while(0)
static sig_atomic_t caught = 0;
static void
sigtrap_handler(int sig, siginfo_t *info, void *ctx)
{
assert(sig == SIGTRAP);
ATF_REQUIRE_EQ(info->si_code, TRAP_TRACE);
++caught;
}
int
main(int argc, char **argv)
{
int error;
struct sigaction act;
ATF_REQUIRE(sigemptyset(&act.sa_mask) == 0);
act.sa_sigaction = sigtrap_handler;
act.sa_flags = SA_SIGINFO;
ATF_REQUIRE(sigaction(SIGTRAP, &act, 0) == 0);
error = exect(NULL, NULL, NULL) == -1;
printf("error=%d errno=%d\n", error, errno);
printf("caught=%d\n", caught);
return 0;
}
>Fix:
N/A
>Release-Note:
>Audit-Trail:
From: "Kamil Rytarowski" <kamil@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/51700 CVS commit: src/tests/lib/libc/gen/exect
Date: Fri, 9 Dec 2016 06:47:48 +0000
Module Name: src
Committed By: kamil
Date: Fri Dec 9 06:47:48 UTC 2016
Modified Files:
src/tests/lib/libc/gen/exect: t_exect.c
Log Message:
Add check in t_exect_null to verify that SIGTRAP was emitted only once
Currently this test fails on amd64.
PR port-amd64/51700
exect(NULL,NULL,NULL) generates 15859 times SIGTRAP on amd64
On FreeBSD/amd64 this tests passes correctly.
Sponsored by <The NetBSD Foundation>
To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 src/tests/lib/libc/gen/exect/t_exect.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Kamil Rytarowski" <kamil@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/51700 CVS commit: src/tests/lib/libc/gen/exect
Date: Fri, 9 Dec 2016 08:34:38 +0000
Module Name: src
Committed By: kamil
Date: Fri Dec 9 08:34:38 UTC 2016
Modified Files:
src/tests/lib/libc/gen/exect: t_exect.c
Log Message:
Restrict atf_tc_expect_fail(PR port-amd64/51700) only for amd64 (x86_64)
Other ports than amd64 have their own issues, mostly keeping this call as
unimplemented.
While there cast sig_atomic_t to int in the printf(3)-like call -- pointed
out by <martin>
Sponsored by <The NetBSD Foundation>
To generate a diff of this commit:
cvs rdiff -u -r1.3 -r1.4 src/tests/lib/libc/gen/exect/t_exect.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Cc:
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)
--mVDohrfhGJl4KDx3cDu9JiGuBdl9t14uF
Content-Type: multipart/mixed; boundary="kwFMJQnhwOSeUsptJJ1MMGmLvXhLtXrTK"
From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Message-ID: <2044468e-027f-b38c-b17e-d9a23c55b820@gmx.com>
Subject: Re: port-amd64/51700: exect(NULL,NULL,NULL) generates 15859 times
SIGTRAP on amd64
References: <pr-port-amd64-51700@gnats.netbsd.org>
<20161209063718.626CA7A364@mollari.NetBSD.org>
<20161209064000.613C97A364@mollari.NetBSD.org>
In-Reply-To: <20161209064000.613C97A364@mollari.NetBSD.org>
--kwFMJQnhwOSeUsptJJ1MMGmLvXhLtXrTK
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
--kwFMJQnhwOSeUsptJJ1MMGmLvXhLtXrTK--
--mVDohrfhGJl4KDx3cDu9JiGuBdl9t14uF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJYSn3cAAoJEEuzCOmwLnZs4y4QAKcHFYX0J2Wo1on76Km9Fsb8
I+KjWqL7yv322xPurEeeRmzPYgxHGGaFachh/J9zJJlQwzrzsaelab3JLgidN6Uw
2odgpNsLh+5MsRFPEXlXEMR06fawHLwUFa+Yw6nCzp2W+4wgPBgaleWsEhq6NI88
ltaqZxFwGbp/bjxDxodoKxVqdtMOslJEXOTXBFanfWRCPVgnMq8QLP8lW/WQD/Qm
ldcpN/Lyh6KOX+eIkc9DkkO82/bBqkeohP5nUY+fFo/57T4088fRqx5JVOT7ywvx
i3/ut1XOzOWlFkD5yWQ75bALHtZwlOJO4pbx/3yHhzDyYmNtJsXCpGYTpUc5WLdM
/KnxeWlYFuXgazMjC/Mr8Zbkv3jOAp+CSYFjgnW1nQ9NnYmERlOTiY+h4w2WWuZK
zr3E+K6QPZ/KJqteZwMmr8SdTkCpT2IrdU1Jrk1U8zaHOSa8NljJQ5VIyeOJkdpx
x60FD7oGsxvGCavBofdxbQYEmi5+PRMQ6YzohqQ+kfFQWq+4ShWLoy340Bz1OGk8
M8dimONdNIKNVwET8Z/RAkaWajlJARao3EsVkHlmNZgK30V/kSyqz4K5un6E19JG
8V82wI+oQvLwRKst/du7zz01rBqHFVa8M+fuPvkbE1RGj0ycgH7b9Aq+deQKz0Uf
mEafBuagI2tNqiV/odZ1
=ltx4
-----END PGP SIGNATURE-----
--mVDohrfhGJl4KDx3cDu9JiGuBdl9t14uF--
From: Kamil Rytarowski <n54@gmx.com>
To: Paul Goyette <paul@whooppee.com>, gnats-bugs@NetBSD.org
Cc:
Subject: Re: port-amd64/51700: exect(NULL,NULL,NULL) generates 15859 times
SIGTRAP on amd64
Date: Fri, 9 Dec 2016 11:38:48 +0100
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--X10K5woipbiTnFcQ0PpAEGSNpqeiHCgO2
Content-Type: multipart/mixed; boundary="9fVl8TJuCd2CMJaA5T2QXqnRS7hsS0VBC"
From: Kamil Rytarowski <n54@gmx.com>
To: Paul Goyette <paul@whooppee.com>, gnats-bugs@NetBSD.org
Message-ID: <d79c070c-cc13-e1f5-b599-e39a9fd38a81@gmx.com>
Subject: Re: port-amd64/51700: exect(NULL,NULL,NULL) generates 15859 times
SIGTRAP on amd64
References: <pr-port-amd64-51700@gnats.netbsd.org>
<20161209063718.626CA7A364@mollari.NetBSD.org>
<20161209095501.35ABE7A330@mollari.NetBSD.org>
<Pine.NEB.4.64.1612091800580.7853@speedy.whooppee.com>
In-Reply-To: <Pine.NEB.4.64.1612091800580.7853@speedy.whooppee.com>
--9fVl8TJuCd2CMJaA5T2QXqnRS7hsS0VBC
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Good point, if exect(3) is going to be a programmer-friendly utility
(and since it already reserves its entry in libc), I'm for a breakpoint
on the main() function.
In that scenario we would get debugger code like:
int status;
child =3D fork();
if (child =3D=3D 0)
exect("/bin/cat", "cat", NULL);
wait(&status);
ptrace(...)
On 09.12.2016 11:03, Paul Goyette wrote:
> Just curious.... (private response, feel free to forward if you find i=
t
> useful)
>=20
>> This sounds to me like exect(3) should be equivalent to PT_TRACE_ME &
>> execve(2) & raise(SIGTRAP with si_code=3D3DTRAP_TRACE) on first instru=
ction
>=20
> The term "first instruction" could be interpreted as the beginning of
> the executable's main() procedure. Or it could be interpreted as the
> beginning of crt0 code for the executable.
>=20
> I'm not sure which one you mean, but whatever decision is made, it need=
s
> to be clearly and unambiguously documented. :)
>=20
>=20
>=20
>=20
> On Fri, 9 Dec 2016, Kamil Rytarowski wrote:
>=20
>> The following reply was made to PR port-amd64/51700; it has been noted=
>> by GNATS.
>>
>> From: Kamil Rytarowski <n54@gmx.com>
>> To: gnats-bugs@NetBSD.org
>> Cc:
>> 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)
>> --mVDohrfhGJl4KDx3cDu9JiGuBdl9t14uF
>> Content-Type: multipart/mixed;
>> boundary=3D"kwFMJQnhwOSeUsptJJ1MMGmLvXhLtXrTK"
>> From: Kamil Rytarowski <n54@gmx.com>
>> To: gnats-bugs@NetBSD.org
>> Message-ID: <2044468e-027f-b38c-b17e-d9a23c55b820@gmx.com>
>> Subject: Re: port-amd64/51700: exect(NULL,NULL,NULL) generates 15859
>> times
>> SIGTRAP on amd64
>> References: <pr-port-amd64-51700@gnats.netbsd.org>
>> <20161209063718.626CA7A364@mollari.NetBSD.org>
>> <20161209064000.613C97A364@mollari.NetBSD.org>
>> In-Reply-To: <20161209064000.613C97A364@mollari.NetBSD.org>
>>
>> --kwFMJQnhwOSeUsptJJ1MMGmLvXhLtXrTK
>> Content-Type: text/plain; charset=3Dwindows-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 solutio=
n
>> is to switch this code to the sequence of raise(3) && execve(2) for al=
l
>> 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 mig=
ht
>> 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=3D3DTRAP_TRACE) on first
>> instruction=3D
>>
>> 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 an=
d
>> absent in OpenBSD
>>
>>
>> --kwFMJQnhwOSeUsptJJ1MMGmLvXhLtXrTK--
>>
>> --mVDohrfhGJl4KDx3cDu9JiGuBdl9t14uF
>> Content-Type: application/pgp-signature; name=3D"signature.asc"
>> Content-Description: OpenPGP digital signature
>> Content-Disposition: attachment; filename=3D"signature.asc"
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2
>>
>> iQIcBAEBCAAGBQJYSn3cAAoJEEuzCOmwLnZs4y4QAKcHFYX0J2Wo1on76Km9Fsb8
>> I+KjWqL7yv322xPurEeeRmzPYgxHGGaFachh/J9zJJlQwzrzsaelab3JLgidN6Uw
>> 2odgpNsLh+5MsRFPEXlXEMR06fawHLwUFa+Yw6nCzp2W+4wgPBgaleWsEhq6NI88
>> ltaqZxFwGbp/bjxDxodoKxVqdtMOslJEXOTXBFanfWRCPVgnMq8QLP8lW/WQD/Qm
>> ldcpN/Lyh6KOX+eIkc9DkkO82/bBqkeohP5nUY+fFo/57T4088fRqx5JVOT7ywvx
>> i3/ut1XOzOWlFkD5yWQ75bALHtZwlOJO4pbx/3yHhzDyYmNtJsXCpGYTpUc5WLdM
>> /KnxeWlYFuXgazMjC/Mr8Zbkv3jOAp+CSYFjgnW1nQ9NnYmERlOTiY+h4w2WWuZK
>> zr3E+K6QPZ/KJqteZwMmr8SdTkCpT2IrdU1Jrk1U8zaHOSa8NljJQ5VIyeOJkdpx
>> x60FD7oGsxvGCavBofdxbQYEmi5+PRMQ6YzohqQ+kfFQWq+4ShWLoy340Bz1OGk8
>> M8dimONdNIKNVwET8Z/RAkaWajlJARao3EsVkHlmNZgK30V/kSyqz4K5un6E19JG
>> 8V82wI+oQvLwRKst/du7zz01rBqHFVa8M+fuPvkbE1RGj0ycgH7b9Aq+deQKz0Uf
>> mEafBuagI2tNqiV/odZ1
>> =3Dltx4
>> -----END PGP SIGNATURE-----
>>
>> --mVDohrfhGJl4KDx3cDu9JiGuBdl9t14uF--
>>
>>
>> !DSPAM:584a7fa116007695620486!
>>
>>
>=20
> +------------------+--------------------------+------------------------=
+
> | Paul Goyette | PGP Key fingerprint: | E-mail addresses: =
|
> | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com =
|
> | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org =
|
> +------------------+--------------------------+------------------------=
+
--9fVl8TJuCd2CMJaA5T2QXqnRS7hsS0VBC--
--X10K5woipbiTnFcQ0PpAEGSNpqeiHCgO2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJYSonAAAoJEEuzCOmwLnZsyecQAJVNrLtV8ijnrz/ibsb2Nxq2
/paXU4zvMdFBbi6zuDpG7wRW3fWgU/iBgvAtXdH+EgALqH8moz0IjYrvevRYmahm
rRAc8LqKrMpuSwbZ6DyknkQoiEowUl6X/aFsynCUBrkYUKQgy/3hEobYamp08qXN
IFSPXloeS6pz8pfMUV4QpuXZ6i9rGNzTgHMe6hh7zq0RmGVJlkhSW/MFGHoJzlFV
gsV1llKD4L5NxYCHZhqu6q9qF2d7SXC9tje/vuNKQOey8UShX6wrUX/LU91huWil
C4idQ7XsIohEY9QPMtjt8cUJI1qPgYMo3fOlogrReW8nYf2Gw09R3xplsJWmHw7X
sjCWoY0gCgPWlo0ucvz38OINNXS9NGHcQEGFsVQH83AcnGsR2KOWxE9bU5BOKij8
kldJZ7TRud9M6AP1NOVR+ZMWnScrY8pFivGymDHNVzNPRNYHdKQpUvEgEezy8Fn9
E1xJ5SuHaa16GTCszVoQ1C29n/msvFmle66coXxPo7ctdS4GLuODrgduuTXIoAyV
zeN3lIrsV4t+Yc3wN5maF2q/MPEtnwz5212JKNRqGhlydRKookvD6iUegRcM+VZs
0Wt8GfYZta0gcmbf7PrsEkVJpH3OcovFnra4XnRjiYgGq98dz0WWwlUoNzUri7QP
eTo2+2WSj5oUmtZwscqu
=BgQR
-----END PGP SIGNATURE-----
--X10K5woipbiTnFcQ0PpAEGSNpqeiHCgO2--
From: "Kamil Rytarowski" <kamil@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/51700 CVS commit: src/tests/lib/libc/gen/exect
Date: Sun, 11 Dec 2016 03:38:09 +0000
Module Name: src
Committed By: kamil
Date: Sun Dec 11 03:38:09 UTC 2016
Modified Files:
src/tests/lib/libc/gen/exect: t_exect.c
Log Message:
Skip t_exect test because it makes test machines to hang
exect(NULL,NULL,NULL) generates 15859 times SIGTRAP on amd64
Currently exect(3) is misdesigned -- see PR port-amd64/51700 and it
needs to be redone from scratch.
This test affects amd64 releng machines causing tests to hang or
fail. As there is little point to test interface that is still not,
designed and implemented and implemented and is breaking tests - skip it
unconditionally for all ports.
Sponsored by <The NetBSD Foundation>
To generate a diff of this commit:
cvs rdiff -u -r1.4 -r1.5 src/tests/lib/libc/gen/exect/t_exect.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: port-amd64-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, n54@gmx.com
Subject: Re: PR/51700 CVS commit: src/tests/lib/libc/gen/exect
Date: Sun, 11 Dec 2016 10:34:14 +0100
On Sun, Dec 11, 2016 at 03:40:00AM +0000, Kamil Rytarowski wrote:
> exect(NULL,NULL,NULL) generates 15859 times SIGTRAP on amd64
> Currently exect(3) is misdesigned -- see PR port-amd64/51700 and it
> needs to be redone from scratch.
I'd argue that it should just be removed.
Martin
From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: PR/51700 CVS commit: src/tests/lib/libc/gen/exect
Date: Sun, 11 Dec 2016 10:33:14 +0100
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--pmiwmr38qOW3o9qWGUUlchqKBB1efEO3b
Content-Type: multipart/mixed; boundary="FpiCraC7p27xTG0kj06FD7e2PWGXUBiuX"
From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Message-ID: <5c70d4be-34de-d13f-e0b3-109271ae0bee@gmx.com>
Subject: Re: PR/51700 CVS commit: src/tests/lib/libc/gen/exect
References: <pr-port-amd64-51700@gnats.netbsd.org>
<20161209063718.626CA7A364@mollari.NetBSD.org>
<20161211093500.D4B697A35D@mollari.NetBSD.org>
In-Reply-To: <20161211093500.D4B697A35D@mollari.NetBSD.org>
--FpiCraC7p27xTG0kj06FD7e2PWGXUBiuX
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 11.12.2016 10:35, Martin Husemann wrote:
> The following reply was made to PR port-amd64/51700; it has been noted =
by GNATS.
>=20
> From: Martin Husemann <martin@duskware.de>
> To: gnats-bugs@NetBSD.org
> Cc: port-amd64-maintainer@netbsd.org, gnats-admin@netbsd.org,
> netbsd-bugs@netbsd.org, n54@gmx.com
> Subject: Re: PR/51700 CVS commit: src/tests/lib/libc/gen/exect
> Date: Sun, 11 Dec 2016 10:34:14 +0100
>=20
> On Sun, Dec 11, 2016 at 03:40:00AM +0000, Kamil Rytarowski wrote:
> > exect(NULL,NULL,NULL) generates 15859 times SIGTRAP on amd64
> > Currently exect(3) is misdesigned -- see PR port-amd64/51700 and it=
> > needs to be redone from scratch.
> =20
> I'd argue that it should just be removed.
> =20
> Martin
> =20
>=20
I concur it, how to do it cleanly? Set backwards compatible link
exect(3) to execve(2) and add a note that it should be removed on major
libc bump?
--FpiCraC7p27xTG0kj06FD7e2PWGXUBiuX--
--pmiwmr38qOW3o9qWGUUlchqKBB1efEO3b
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJYTR1nAAoJEEuzCOmwLnZsmyMP/0S2tue+cM9uBbozGNKeqdtQ
/334igc33t+bF5Rs5ZlKzAonRcnOfKrcPjJHicvptg+l9Gk6BK9ZcwRiuHycr5/c
2BhW7CtkAYfliXpxKkkfPCnu6btUsKI2k2RGtLm+yASF/ubBQV2Ywxr3k+fjJT1C
fX62/o2/S9OeGygNi3NjJl02w2l4IGibO3waZLgpD4j2AAMr0vSB/pfqTHVGaVYB
5767Acfhck1pnOAnsTblGGXlgW4MGZxKVF67JbrgSfQGwqZ725IPdjyUQanM9yEK
L9jBNi4WVQZ8+PSahikxxwv6is+8Bd1wEBgJGQZ94jQDn//p4TMihdebooygFeNl
L20DSAFLE6Tb9EqYNgxIVpoWxjFwcrFc6krp32RQFp0dsNJqXXtwpwo3A29zWQ0w
QlwhY9l2OpcEZHwniaU+4o7lxNWZL7zi41oSfxijEVcRRDWrkNlARAwKlcpMFLri
2wlDYACVfCyJ9eZ++tb3Eyn06nHq5tfOsP6JME4Jd5hOffRIxJtsz2r779umBsl3
uUFhqXYaKh4t/3MJHMwjYrUWtmWc2m657SsQ+hqTZBp/FD8f9fB4jZ40Z3ak7krA
iWm5c6JbO2UhQaRxVXVM3OG/2ejA14IHtSNOUkoBuKFCGxI1JHp/R6YVv4+g2v9P
4D712uFadp+usaDjAx++
=dbvL
-----END PGP SIGNATURE-----
--pmiwmr38qOW3o9qWGUUlchqKBB1efEO3b--
Responsible-Changed-From-To: port-amd64-maintainer->kern-bug-people
Responsible-Changed-By: dholland@NetBSD.org
Responsible-Changed-When: Mon, 16 Jan 2017 04:13:10 +0000
Responsible-Changed-Why:
details may be port-specific but the overall problem seems to be MI
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: PR/51700 CVS commit: src/tests/lib/libc/gen/exect
Date: Mon, 16 Jan 2017 04:15:28 +0000
On Sun, Dec 11, 2016 at 09:40:01AM +0000, Kamil Rytarowski wrote:
>> I'd argue that it should just be removed.
>
> I concur it, how to do it cleanly? Set backwards compatible link
> exect(3) to execve(2) and add a note that it should be removed on major
> libc bump?
No, if it's never going to work replace it with a stub that returns -1
with errno EOPNOTSUPP, one in the kernel and one in libc. Then remove
the libc stub when the mythical version bump happens.
exect is historical, but I don't think that means we need to keep it;
any vintage debugger that someone might dig up in a basement will need
a lot of porting work anyway, and it's not like there have ever been a
lot of unix debuggers around.
--
David A. Holland
dholland@netbsd.org
From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: PR/51700 CVS commit: src/tests/lib/libc/gen/exect
Date: Mon, 16 Jan 2017 05:27:13 +0100
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--rrqUJqKxv740uG4kiKoUPv00sJ70VIwoe
Content-Type: multipart/mixed; boundary="RrEp93TMQ40PoXLV2SKvCVMni6PdfdaRm";
protected-headers="v1"
From: Kamil Rytarowski <n54@gmx.com>
To: gnats-bugs@NetBSD.org
Message-ID: <35787b2b-f28b-cf89-9b07-1d54c5efc710@gmx.com>
Subject: Re: PR/51700 CVS commit: src/tests/lib/libc/gen/exect
References: <pr-kern-51700@gnats.netbsd.org>
<20161209063718.626CA7A364@mollari.NetBSD.org>
<20170116042001.59CEB7A1AF@mollari.NetBSD.org>
In-Reply-To: <20170116042001.59CEB7A1AF@mollari.NetBSD.org>
--RrEp93TMQ40PoXLV2SKvCVMni6PdfdaRm
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 16.01.2017 05:20, David Holland wrote:
> The following reply was made to PR kern/51700; it has been noted by GNA=
TS.
>=20
> From: David Holland <dholland-bugs@netbsd.org>
> To: gnats-bugs@NetBSD.org
> Cc:=20
> Subject: Re: PR/51700 CVS commit: src/tests/lib/libc/gen/exect
> Date: Mon, 16 Jan 2017 04:15:28 +0000
>=20
> On Sun, Dec 11, 2016 at 09:40:01AM +0000, Kamil Rytarowski wrote:
> >> I'd argue that it should just be removed.
> > =20
> > I concur it, how to do it cleanly? Set backwards compatible link
> > exect(3) to execve(2) and add a note that it should be removed on =
major
> > libc bump?
> =20
> No, if it's never going to work replace it with a stub that returns -1=
> with errno EOPNOTSUPP, one in the kernel and one in libc. Then remove
> the libc stub when the mythical version bump happens.
> =20
It's broken since day0. No need to add a stub in the kernel, it's only
in libc.
> exect is historical, but I don't think that means we need to keep it;
> any vintage debugger that someone might dig up in a basement will need=
> a lot of porting work anyway, and it's not like there have ever been a=
> lot of unix debuggers around.
> =20
Current execve(2) has the close meaning of legacy exect(3) anyway. For
that legacy debugger just replace exect(3) with execve(2) call. We
generate SIGTRAP & TRAP_EXEC unconditionally from exec() inside the
kernel under a debugger.
The original meaning of exect(3) was to enable vax-specific (and on
386bsd 80386-specific) PT_STEP bit for a process and call execve(2). It
was questionable because:
1. enabling it without attached debugger is insane
2. very MD-specific implementation
3. it need to perform steps hundreds of steps before switch to a new proc=
ess
It's also not that useful, as there are more convenient replacements of
the execve(2) semantics, like execlp(3) and others.
> --=20
> David A. Holland
> dholland@netbsd.org
> =20
>=20
--RrEp93TMQ40PoXLV2SKvCVMni6PdfdaRm--
--rrqUJqKxv740uG4kiKoUPv00sJ70VIwoe
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJYfEuxAAoJEEuzCOmwLnZsfbwQAJzDtcvvv7PE2K+FMJhs5fPS
t7Cp9XjoOOA/CvDhbPKlcRqAB3QHr1SbVssoTKfbI80javSCIDPFedqPa5+Qvqrb
5W3fb7RECxkV5sUzCjKIDdqgrJk8lxyFI8BdUwab0ZYGZrHByzMSseTvlGwjbn/F
P5wlvLiEG9HreFhGRlRBkLNhBq/HSQjeBhtGDKtypESl9+LbNQ7WaTd6rGPCNUwk
lWCKpi09V3zvFaDt98XeZpluwpl2Cl2AlOaxAS4UaDQzifvy30ZWwxicWoptnBxn
vtwWUHxoxDqChYm0qLTF3FOQNb91D7iHd2CSidbdMlVRG1ZVRzU16BOgHUyyLGUz
pGNGpQpWSzoiCHgmPcyvHKed5P1YhVgMcHeEbeOf7Vq7433Wf7ZTnb0RiW38t1te
xt7oudgAoWUhUn+HI52RUdmEVTtKBJZDXeod1k5bMmjYVDlvu2RirbXuRBvPGa1C
T2Lq/3OWt9v/k34uQ7joqB+xDwwgoSdK/QEZbJgu286jDAR7dW/0wmyvkT9JUqEG
lYyFljVac+FzdzumsGGxkD6nvP+9fvRnZzxb5TGsFP0YV/tvK+2HhM4ADjXm45d2
JYotltsmk+dD0TK4xgfhLD2PVksicmrvyG3b3ccnq2GvTeQRvtlWyZfejnr0PSUk
zzfCypQSBILiU+tKD4po
=T5VM
-----END PGP SIGNATURE-----
--rrqUJqKxv740uG4kiKoUPv00sJ70VIwoe--
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: PR/51700 CVS commit: src/tests/lib/libc/gen/exect
Date: Sun, 22 Jan 2017 21:22:33 +0000
On Mon, Jan 16, 2017 at 04:35:00AM +0000, Kamil Rytarowski wrote:
>> No, if it's never going to work replace it with a stub that returns -1
>> with errno EOPNOTSUPP, one in the kernel and one in libc. Then remove
>> the libc stub when the mythical version bump happens.
>
> It's broken since day0. No need to add a stub in the kernel, it's only
> in libc.
ah, for some reason I thought there was a kernel protrusion of that.
In that case just libc, and also give it warn_references or
error_references. And note in shlib_version to get rid of it later.
--
David A. Holland
dholland@netbsd.org
From: "Kamil Rytarowski" <kamil@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/51700 CVS commit: src/lib/libc
Date: Tue, 7 Feb 2017 19:29:40 +0000
Module Name: src
Committed By: kamil
Date: Tue Feb 7 19:29:40 UTC 2017
Modified Files:
src/lib/libc/gen: Makefile.inc
src/lib/libc/sys: Makefile.inc
Added Files:
src/lib/libc/gen: exect.c
Removed Files:
src/lib/libc/arch/aarch64/sys: exect.S
src/lib/libc/arch/alpha/sys: exect.S
src/lib/libc/arch/arm/sys: exect.S
src/lib/libc/arch/hppa/sys: exect.S
src/lib/libc/arch/i386/sys: exect.S
src/lib/libc/arch/ia64/sys: exect.S
src/lib/libc/arch/m68k/sys: exect.S
src/lib/libc/arch/mips/sys: exect.S
src/lib/libc/arch/or1k/sys: exect.S
src/lib/libc/arch/powerpc/sys: exect.S
src/lib/libc/arch/powerpc64/sys: exect.S
src/lib/libc/arch/riscv/sys: exect.S
src/lib/libc/arch/sh3/sys: exect.S
src/lib/libc/arch/sparc/sys: exect.S
src/lib/libc/arch/sparc64/sys: exect.S
src/lib/libc/arch/vax/sys: exect.S
src/lib/libc/arch/x86_64/sys: exect.S
src/lib/libc/sys: Lint_exect.c
Log Message:
Mark exect(3) obsolete and bind it to plain execve(2) on all platforms
The original exect(2) from BSD4.2 was enabling bit for tracing
(single-step mode) and calling execve(2). The purpose of it was to generate
a signal for a tracer once the application will change its image to a new
program.
This approach no longer works as:
- exect(2) traces (single-steps) libc and it requires hundreds or
thousands steps before entering a new image
- it's vax and x86 specific code
- this functionality has been moved to the kernel - once a process is
traced it will generate SIGTRAP with si_code TRAP_EXEC and route it to
its debugger
- the side effects and unportability make this interface unusable
- there are no known users of this interface
- it apparently never worked better since day0 of NetBSD ("day0 bug")
Users are requested to move to other execve(2) variants. Calling current
execve(2) as it is the most similar behavior to this one from BSD4.2.
Discussed several times on mailing lists and in PR/51700.
Add warning to exect(3) telling about marking this function obsolete.
This function is prepared to be removed in next libc major bump.
Sponsored by <The NetBSD Foundation>
To generate a diff of this commit:
cvs rdiff -u -r1.1 -r0 src/lib/libc/arch/aarch64/sys/exect.S
cvs rdiff -u -r1.3 -r0 src/lib/libc/arch/alpha/sys/exect.S
cvs rdiff -u -r1.4 -r0 src/lib/libc/arch/arm/sys/exect.S
cvs rdiff -u -r1.2 -r0 src/lib/libc/arch/hppa/sys/exect.S
cvs rdiff -u -r1.15 -r0 src/lib/libc/arch/i386/sys/exect.S
cvs rdiff -u -r1.2 -r0 src/lib/libc/arch/ia64/sys/exect.S
cvs rdiff -u -r1.8 -r0 src/lib/libc/arch/m68k/sys/exect.S
cvs rdiff -u -r1.10 -r0 src/lib/libc/arch/mips/sys/exect.S
cvs rdiff -u -r1.1 -r0 src/lib/libc/arch/or1k/sys/exect.S
cvs rdiff -u -r1.3 -r0 src/lib/libc/arch/powerpc/sys/exect.S
cvs rdiff -u -r1.1 -r0 src/lib/libc/arch/powerpc64/sys/exect.S
cvs rdiff -u -r1.1 -r0 src/lib/libc/arch/riscv/sys/exect.S
cvs rdiff -u -r1.5 -r0 src/lib/libc/arch/sh3/sys/exect.S
cvs rdiff -u -r1.3 -r0 src/lib/libc/arch/sparc/sys/exect.S
cvs rdiff -u -r1.2 -r0 src/lib/libc/arch/sparc64/sys/exect.S
cvs rdiff -u -r1.6 -r0 src/lib/libc/arch/vax/sys/exect.S
cvs rdiff -u -r1.4 -r0 src/lib/libc/arch/x86_64/sys/exect.S
cvs rdiff -u -r1.197 -r1.198 src/lib/libc/gen/Makefile.inc
cvs rdiff -u -r0 -r1.1 src/lib/libc/gen/exect.c
cvs rdiff -u -r1.2 -r0 src/lib/libc/sys/Lint_exect.c
cvs rdiff -u -r1.231 -r1.232 src/lib/libc/sys/Makefile.inc
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->closed
State-Changed-By: kamil@NetBSD.org
State-Changed-When: Mon, 04 Jun 2018 11:46:04 +0200
State-Changed-Why:
exect(3) has been marked obsolete
its functionality has been moved long time ago into the kernel that now fires SIGTRAP for the exec(3) event
FreeBSD decided recently to reimplement their exect(3) with PT_TRACE_ME + execve(2), but it has no purpose.
OpenBSD has removed exect(3) long time ago.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home