From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from xry111.site (xry111.site [89.208.246.23]) by sourceware.org (Postfix) with ESMTPS id 39F5039528D6 for ; Fri, 7 Jun 2024 09:06:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 39F5039528D6 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=xry111.site Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=xry111.site ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 39F5039528D6 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=89.208.246.23 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717751199; cv=none; b=k7LIWyN/UOOszlVNxlK/gPiKwZO2EsjeziP4HjLOmvNKQTze8SJLbxDV2AEVQAjOc8fOU8P10QcZ8nTOJ46VjEy+N3Sf3BOHTiYeyQCpTqHfndSs9/mA2xaPcC9HfDmyWBfGRyExYBqz3MA8fXrDnjw+7Gb5HSpmcK/4baRsXBI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717751199; c=relaxed/simple; bh=fhcYi9BE+dZHAdxuWkQOa5WrN5kLy4n/4N+FvhcHlow=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=j4qkXx/z+b7oroV167I0L2JOJL5zDfJr+C9sW7uOZVoWj+tgKZF/Goad+4Z2SitkPeVsnZo3Nl13nZAbyDnCZXcwS1lMpXDIhGqMNQa1ARTwJFcjl4ewiLkHzoh9jgKOsJBIBVxBc0KS83oUtKNua33cDia5sRnDFZXn6W7o9M8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site; s=default; t=1717751196; bh=fhcYi9BE+dZHAdxuWkQOa5WrN5kLy4n/4N+FvhcHlow=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=g56JhUDr/UYNA374/0Q2uAu5pIymV8c2E1NQZ3BaZGYZgW13R+MgekyUXcxoj8ulu GetK6QA1huIglAklmU+nkrsQDSBK7TBPrvPq25uB8tnb7bqjpSPCVH4WD0hVVzmky8 xArOQ8I1oHwarH5Yjiqb1tcvx/dUkIDIyjK7Xowk= Received: from [127.0.0.1] (unknown [IPv6:2001:470:683e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) (Authenticated sender: xry111@xry111.site) by xry111.site (Postfix) with ESMTPSA id 0888E66452; Fri, 7 Jun 2024 05:06:35 -0400 (EDT) Message-ID: Subject: Re: [PATCH 3/6] linux: Implement mremap in C From: Xi Ruoyao To: Adhemerval Zanella Netto , enh , Florian Weimer Cc: libc-alpha@sourceware.org, Stafford Horne Date: Fri, 07 Jun 2024 17:06:34 +0800 In-Reply-To: <177225da-682e-4f57-9cde-5ff8f366266a@linaro.org> References: <20211122185437.1934590-1-adhemerval.zanella@linaro.org> <20211122185437.1934590-4-adhemerval.zanella@linaro.org> <87y17iqf07.fsf@oldenburg3.str.redhat.com> <177225da-682e-4f57-9cde-5ff8f366266a@linaro.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.52.2 MIME-Version: 1.0 X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,LIKELY_SPAM_FROM,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, 2024-06-06 at 17:26 -0300, Adhemerval Zanella Netto wrote: > I don't really recall to be honest.=C2=A0 And I don't have a strong opini= on,=20 > the main issue is I would like to eventually get rid of the assembly > hooks for the syscall auto-generation so we only have have it to support > for generate it through C.=C2=A0 Besides the code simplification it has t= he > side effect of playing better the LTO (which we still do not fully suppor= t, > but maybe in the future). >=20 > I had a prototype for this, which also is slight faster since it generate= s > the files in a bulk. But GCC is generating some really stupid code for va_list. I made https://sourceware.org/pipermail/libc-alpha/2023-March/146624.html to "work it around" but the patch was NAK'ed for some good reason (not to invoke UB). With a simple example: #include int func(int flag, int arg, ... /*int optional*/) { if (!flag) return arg | 42; else { va_list ap; va_start(ap, arg); arg |=3D va_arg(ap, int); va_end(ap); } return arg; } int func_ub(int flag, int arg, int optional) { if (!flag) return arg | 42; else return arg | optional; } we can demonstrate how the code generation for func is much worse than func_ub. Clang produces even more stupid code. I hope someone can work on improving the compilers if we must use va_list more and more... > Besides the code simplification it has the side effect of playing > better the LTO (which we still do not fully support, but maybe in the > future). Note that with LTO invoking UB deliberately won't be an option at all (it is an option w/o LTO but already a really bad option). So we need some support from the compiler or we'll have to eat the stupid code from va_list. BTW has someone built Glibc with LTO? I tried it and it never worked. --=20 Xi Ruoyao School of Aerospace Science and Technology, Xidian University