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 B267977FEC for ; Tue, 27 Mar 2018 19:22:31 +0000 (UTC) Received: from seebsdell (unknown [24.196.59.174]) by mail.seebs.net (Postfix) with ESMTPSA id DE28E2E8928; Tue, 27 Mar 2018 14:22:31 -0500 (CDT) Date: Tue, 27 Mar 2018 14:22:30 -0500 From: Seebs To: Andre McCurdy Message-ID: <20180327142230.15f1abf9@seebsdell> In-Reply-To: References: <20180326143107.48f153a5@seebsdell> <20180326160746.1dce7ae9@seebsdell> <20180326203209.2da967eb@seebsdell> <20180326210734.165ac038@seebsdell> <20180326234108.4b52c066@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 19:22:31 -0000 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 27 Mar 2018 12:11:22 -0700 Andre McCurdy wrote: > In the readahead example, the first syscall argument is the > 32bit file descriptor (which will be passed to the kernel in r0), > therefore a padding argument is required to fill r1 and ensure that > the first word of the 64bit offset gets passed in r2. Yes. > The above is completely specific to ARM 32bit EABI. I guess *similar* > issues may apply to some other 32bit architectures (as suggested in > the manpage). It's certainly not an issue with is generic to all 32bit > targets though. I was wondering about 64-bit EABI. The man page didn't say "32-bit EABI", it said "EABI". The information that you don't need to do that on at least some ARM EABI arguably makes this *worse*, rather than *better*, from the standpoint of "how do I write correct code for this". So this appears to be at least partially a documentation error, although it's quite possible that the text predates the question having come up. But it does also mean that it should be harmless to us in this case. > If syscall(), or a wrapper for it, *does* need to interpret the > arguments for a particular syscall then the syscall() implementation > would have to also agree with the interpretation of the data defined > by the kernel. Yes. My basic concern is that I don't think I have enough information to produce a Provably Correct handling for syscall arguments in the presence of at least one architecture where argument order can change for at least one syscall. ... That said, an actual *correct* wrapper for renameat2 turns out to be surprisingly hard, mostly because EXCHANGE is impossible to do with pseudo's current IPC data structure. -s