From owner-freebsd-amd64@FreeBSD.ORG Sun Dec 5 17:30:17 2010 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0810D1065695 for ; Sun, 5 Dec 2010 17:30:17 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D02C48FC12 for ; Sun, 5 Dec 2010 17:30:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oB5HUGWd014876 for ; Sun, 5 Dec 2010 17:30:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oB5HUGkY014873; Sun, 5 Dec 2010 17:30:16 GMT (envelope-from gnats) Date: Sun, 5 Dec 2010 17:30:16 GMT Message-Id: <201012051730.oB5HUGkY014873@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Kostik Belousov Cc: Subject: Re: amd64/124134: [kernel] The kernel doesn't follow the calling convention in the SVR4/i386 ABI X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kostik Belousov List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Dec 2010 17:30:17 -0000 The following reply was made to PR amd64/124134; it has been noted by GNATS. From: Kostik Belousov To: pfgshield-freebsd@yahoo.com Cc: avg@freebsd.org, freebsd-amd64@freebsd.org, bug-followup@freebsd.org Subject: Re: amd64/124134: [kernel] The kernel doesn't follow the calling convention in the SVR4/i386 ABI Date: Sun, 5 Dec 2010 19:24:55 +0200 --2B/JsCI69OhZNC5r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 05, 2010 at 07:08:07AM -0800, pfgshield-freebsd@yahoo.com wrote: > The code has certainly changed a lot ... >=20 > Reading the posting on the link with a possible fix: >=20 > "... > Can you try to add to kernel sources, into file sys/amd64/amd64/machdep.c > function exec_setregs(td, entry, stack, ps_strings) > somewhere at the end >=20 > pcb->pcb_flags |=3D PCB_FULLCTX; > ... " >=20 > We don't have anything similar to this in exec_setregs(), and from my und= erstanding the issue could not be easily fixed without breaking binary comp= atibility so I would think the issue is still there. >=20 > This PR was only for reference though as it doesn't cause trouble for us:= I'm OK with the PR being closed. >=20 I looked at the PR before. Looking again now, I have the same conclusion, that is I do not understand what is the issue. On the first return into usermode after the successfull execve(2), kernel sets the following registers: - %rsp (properly aligned) - %rdi (1st parameter in usermode ABI; contains the pointer to startup frame, i.e. &argc) - all other GP registers are zeroed. ABI rev. 0.99 requires the following setup: - %rsp properly aligned and has the value &argc - %rdx points to a function to be registered with atexit(3), or NULL. We do satisfy the ABI requirement for %rdx content in the trivial way, by passing 0. The layout of the startup frame also seems conforming. --2B/JsCI69OhZNC5r Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkz7yuYACgkQC3+MBN1Mb4g0+gCdHr3LI4WutdnTD8He0+hFYF72 Z6IAoMXjfMPwXwmBlJhaxXlG+gV9vs4t =yePc -----END PGP SIGNATURE----- --2B/JsCI69OhZNC5r--