From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.seebs.net (mail.seebs.net [162.213.38.76]) by mail.openembedded.org (Postfix) with ESMTP id 6AE9E60290 for ; Tue, 27 Mar 2018 04:41:08 +0000 (UTC) Received: from seebsdell (unknown [24.196.59.174]) by mail.seebs.net (Postfix) with ESMTPSA id 60E5C2E8938; Mon, 26 Mar 2018 23:41:10 -0500 (CDT) Date: Mon, 26 Mar 2018 23:41:08 -0500 From: Seebs To: Andre McCurdy Message-ID: <20180326234108.4b52c066@seebsdell> In-Reply-To: References: <20180326143107.48f153a5@seebsdell> <20180326160746.1dce7ae9@seebsdell> <20180326203209.2da967eb@seebsdell> <20180326210734.165ac038@seebsdell> X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Cc: OE-core Subject: Re: pseudo: host user contamination X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2018 04:41:09 -0000 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 26 Mar 2018 19:59:09 -0700 Andre McCurdy wrote: > The syscall manpage is from the kernel manpages, not glibc. > http://man7.org/linux/man-pages/man2/syscall.2.html And yet! glibc is setting those registers in its code. Why? If that's a kernel thing and libc doesn't need to do it, why is libc doing it? If it's "useful background information", what exactly is it "useful" for? > Personally, I've read the manpage, I've read code in glibc and musl, > I've straced coreutils mv and various little test programs on 32bit > ARM plus 32bit and 64bit x86 and written a wrapper for libc syscall() > which either intercepts or passes through syscalls. Okay, you've read the code in glibc and understand it. So, why does the glibc code have that register-setting assembly, if that register-setting assembly doesn't matter? You've told me several times that we don't need to think about the register-setting code. So why did glibc include it? > Everything I've > found seems to be consistent to the point that I've satisfied myself > that I have a pretty clear understanding of how libc syscall() works, > including why ARM EABI sometimes needs an extra argument to offset > 64bit values - and when it matters for a wrapper and when it doesn't. > I don't think there's much more I can do. Okay, you say you understand why ARM EABI "sometimes" needs an argument to offset things. What are the circumstances? Is it specific to 32-bit targets? On a target with 64-bit pointers, would it apply also to 64-bit pointers, or is it exclusively for 64-bit integers? Because it seems to me that on a 64-bit target, renameat2() would in fact be passing a 64-bit object as the second argument. And if there's a reason that this doesn't count as a 64-bit argument passed after an odd number of 32-bit arguments, I'd like to know specifically what that reason is before I go relying on it to stay true forever. -s