From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id 4F4693887000 for ; Mon, 13 Apr 2020 15:17:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4F4693887000 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fw@deneb.enyo.de Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jO0py-0007ia-Mw; Mon, 13 Apr 2020 15:17:26 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1jO0py-0002ZF-GV; Mon, 13 Apr 2020 17:17:26 +0200 From: Florian Weimer To: "H.J. Lu" Cc: "H.J. Lu via Libc-alpha" Subject: Re: [PATCH 2/3] x32: Properly pass long to syscall [BZ #25810] References: <20200413142515.16619-1-hjl.tools@gmail.com> <20200413142515.16619-3-hjl.tools@gmail.com> <8736974fag.fsf@mid.deneb.enyo.de> Date: Mon, 13 Apr 2020 17:17:26 +0200 In-Reply-To: (H. J. Lu's message of "Mon, 13 Apr 2020 08:03:04 -0700") Message-ID: <87y2qz2z5l.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-20.4 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2020 15:17:30 -0000 * H. J. Lu: > On Mon, Apr 13, 2020 at 7:43 AM Florian Weimer wrote: >> >> * H. J. Lu via Libc-alpha: >> >> > diff --git a/sysdeps/unix/sysv/linux/x86_64/sysdep.h b/sysdeps/unix/sysv/linux/x86_64/sysdep.h >> > index 06e39212ee..93dad97c8f 100644 >> > --- a/sysdeps/unix/sysv/linux/x86_64/sysdep.h >> > +++ b/sysdeps/unix/sysv/linux/x86_64/sysdep.h >> > @@ -219,12 +219,14 @@ >> > /* Registers clobbered by syscall. */ >> > # define REGISTERS_CLOBBERED_BY_SYSCALL "cc", "r11", "cx" >> > >> > -/* Create a variable 'name' based on type 'X' to avoid explicit types. >> > - This is mainly used set use 64-bits arguments in x32. */ >> > -#define TYPEFY(X, name) __typeof__ ((X) - (X)) name >> > +/* This also works when X is an array. */ >> > +#define TYPEFY1(X) __typeof__ ((X) - (X)) >> >> I think the comment is now misleading. For an array X, (X) - (X) is >> of type ptrdiff_t, which is signed, so it triggers sign extension, not > > I will update the comments. Thanks. >> zero extension, in the x32 case. I think this is the reason why my >> proposed construct went astray in your experiments. >> >> Is it really necessary to support arrays for system call arguments? > > int > fexecve (int fd, char *const argv[], char *const envp[]) > { > if (fd < 0 || argv == NULL || envp == NULL) > { > __set_errno (EINVAL); > return -1; > } > > #ifdef __NR_execveat > /* Avoid implicit array coercion in syscall macros. */ > INLINE_SYSCALL (execveat, 5, fd, "", &argv[0], &envp[0], AT_EMPTY_PATH); > > "" is an array. If that were the only reason for enforcing pointer decay, I'd say we'd change the fexecve implementation. But see below. >> > diff --git a/sysdeps/unix/sysv/linux/x86_64/x32/sysdep.h b/sysdeps/unix/sysv/linux/x86_64/x32/sysdep.h >> > index 2b5cf0c0ea..f3bc7e89df 100644 >> > --- a/sysdeps/unix/sysv/linux/x86_64/x32/sysdep.h >> > +++ b/sysdeps/unix/sysv/linux/x86_64/x32/sysdep.h >> > @@ -44,6 +44,24 @@ >> > # define ZERO_EXTEND_5 movl %r8d, %r8d; >> > # undef ZERO_EXTEND_6 >> > # define ZERO_EXTEND_6 movl %r9d, %r9d; >> > +#else /*! __ASSEMBLER__ */ >> > +# undef ARGIFY >> > +/* For x32, cast >> > + 1. pointer to unsigned long (32 bit). >> > + 2. 32-bit unsigned integer to unsigned long long (64 bit). >> > + 3. 32-bit integer to long long (64 bit). >> > + */ >> > +# define ARGIFY(X) \ >> > + ({ \ >> > + _Pragma ("GCC diagnostic push"); \ >> > + _Pragma ("GCC diagnostic ignored \"-Wpointer-to-int-cast\""); \ >> > + (__builtin_classify_type (X) == 5 \ >> > + ? (unsigned long) (X) \ >> > + : ((sizeof (X) <= 4 && (TYPEFY1 (X)) 0 < (TYPEFY1 (X)) -1) \ >> > + ? (unsigned long long) (X) \ >> > + : (long long) (X))); \ >> > + _Pragma ("GCC diagnostic pop"); \ >> > + }) >> > #endif /* __ASSEMBLER__ */ >> >> This should use long int instead long everywhere. > > I will update. > >> __builtin_classify_type is undocumented. I'm not sure if its behavior >> and the constant 5 is actually stable across GCC versions, but the >> powerpc uses it as well, for a slightly difference purpose (to >> recognize array arguments, it seems). > > include/libc-pointer-arith.h has > > /* 1 if 'type' is a pointer type, 0 otherwise. */ > # define __pointer_type(type) (__builtin_classify_type ((type) 0) == 5) > > If __builtin_classify_type ever changes, glibc won't build correctly. I see. In this case, can we solely rely on __builtin_classify_type? I dont't think the inner ternary operator is necessary. /* Enforce zero-extension for pointers and array system call arguments. For integer types, extend to long long int (the full register) using a regular cast, resulting in zero or sign extension based on the signed-ness of the original type. */ #define ARGIFY(X) \ ({ \ _Pragma ("GCC diagnostic push"); \ _Pragma ("GCC diagnostic ignored \"-Wpointer-to-int-cast\""); \ (__builtin_classify_type (X) == 5 \ ? (long long int) (uintptr_t) (X) \ : (long long int) (X))); \ _Pragma ("GCC diagnostic pop"); \ }) (Untested, sorry.)