From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105958 invoked by alias); 17 Aug 2017 21:34:51 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 104677 invoked by uid 89); 17 Aug 2017 21:34:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=our X-HELO: hall.aurel32.net Date: Thu, 17 Aug 2017 21:34:00 -0000 From: Aurelien Jarno To: Adhemerval Zanella Cc: "Maciej W. Rozycki" , Joseph Myers , libc-alpha@sourceware.org Subject: Re: [PATCH] mips/o32: fix internal_syscall5/6/7 Message-ID: <20170817213444.lpkfyvntbjjk6f7u@aurel32.net> Mail-Followup-To: Adhemerval Zanella , "Maciej W. Rozycki" , Joseph Myers , libc-alpha@sourceware.org References: <20170815200812.6kmv554yfga2x4al@aurel32.net> <39ca6099-2a86-f5f4-30fe-e86bb4cd736b@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <39ca6099-2a86-f5f4-30fe-e86bb4cd736b@linaro.org> User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2017-08/txt/msg00829.txt.bz2 On 2017-08-17 18:09, Adhemerval Zanella wrote: > > > On 17/08/2017 17:34, Maciej W. Rozycki wrote: > > On Thu, 17 Aug 2017, Adhemerval Zanella wrote: > > > >> My point is I think we should aim for compiler optimization safeness > >> (to avoid code breakage over compiler defined default flags) and taking > >> as base current approach to *avoid* VLA on GLIBC I do not think it is > >> good approach to use it as a bridge to force GCC to generate the expected > >> code. > > > > You certainly have a point here overall, although I don't think a VLA > > whose size is always 0 really hurts. And we've used the approach with > > `alloca' since forever with no adverse effects until we added a place > > where the caller invokes the syscall wrapper in a loop. So I wouldn't > > necessarily call it an issue. Mind that this is target-specific code, so > > we can rely on a target-specific execution model rather than limiting > > ourselves to what generic ISO C guarantees. > > > > Aurelien's figures indicating a clear size reduction certainly count as a > > pro though. > > Joseph pointed out another advantage of avoid VLAs (building with > -Werror=alloca -Werror=vla). My main problem here is we are betting that > compiler won't mess with our assumptions and generate the desirable code > without trying to adhere what it is suppose to provide. Target generic > ISO C give us a better guarantee and any deviation indicates a possible > compiler issue, not otherwise (such this case). My another point is we > can optimize if required later if this is the case and imho this is hardly > the case here (at least for latency). > > If I understood correctly Aurelien's suggestion of returning err in v1 > is not ABI strictly so it will end up calling __libc_do_syscall with a > non-conformant ABI convention (similar to pipe implementation where requires > assembly specific implementation for a lot of architectures to get this > right). Again this is something I would really to avoid. > In the ABI v1 is used in pair with v0 to return 64-bit values. In my patch the __libc_do_syscall is declared as returning a long long. The value is then split using a union, in a similar way to what is already done for the mips16 code. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net