Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4484626imu; Tue, 8 Jan 2019 00:42:07 -0800 (PST) X-Google-Smtp-Source: ALg8bN6q0LPe9ZikPE8O5c+kQ+JQD3MJ25dasxkgrB8xMeFN3liTOWaMxQ9PtK2uTUOoHxlKxgCN X-Received: by 2002:a17:902:8f83:: with SMTP id z3mr847369plo.328.1546936927699; Tue, 08 Jan 2019 00:42:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546936927; cv=none; d=google.com; s=arc-20160816; b=GJqbFONbcnnAmkaMKyMworQCL1uNyGREwwVD+uC8d6g0Wmrovw42H/T4DZjw2rQ2NO CBDD9S2tvYHMEICZuNr6n+Dg6XhdfC1v+Y78XUPeV8LPS0q4gxI1ilbRdno8cDFalBGJ yugwxiWmIq7iHuL0cPgUgglvwWPLJZROkenM/TqpESk0RLWT2yJqj7Tucq4nNUpORJZD q4P8pMDYQqO9NxHv/Y15axoawZEX7nLcyeQjnvD2L98Wd2QQZCs4DLmMUbEEQf8k3g39 6a8+AMy4UDDPvP0OVEFyaVLCZf2bqEqhEgqh0sqX9h03XtDfcWGkSOOCCqh0hmzmdxWE 3UIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:from:cc:to:subject :content-transfer-encoding:mime-version:references:in-reply-to :user-agent:date; bh=FMuJZxc7mzOMx6s1fNhz48p6w9l0Cm+KSJOT14iNOBU=; b=ygaeh6HemMZLSaerk/Q0fjtPszSJzIA+CewKoSxamcY5cvbw0896N3rFfLSe3dTb7t pKZ6rCuswJlvbn5xeirvgFEsIXVxR+Kzg6W0rFZvGxrKPaboukQ8xYCDl/uDiNDhmYnC BPnnAb6Ofc+iz5r5mC3sQBAd2MV7l0GSIlGqwd4kOy/L2Dh6BHE7yAhegFgwNo2eHfYl gyhkJ7GqsZ8Gekx4lWWncWqxAg6NeoLHUvrukPF32K+XzmnjtGtDGIXv5uJ4++XjARkF RLAom7GT18WGLRrhXWihOlcs4sBJrSDtsG/m0ablVWvgbhUv9zS6+fojUIwjXSNcQxU+ G7GA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 13si48349966pld.398.2019.01.08.00.41.52; Tue, 08 Jan 2019 00:42:07 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727838AbfAHIi4 convert rfc822-to-8bit (ORCPT + 99 others); Tue, 8 Jan 2019 03:38:56 -0500 Received: from terminus.zytor.com ([198.137.202.136]:50857 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727368AbfAHIi4 (ORCPT ); Tue, 8 Jan 2019 03:38:56 -0500 Received: from wld62.hos.anvin.org (c-24-5-245-234.hsd1.ca.comcast.net [24.5.245.234] (may be forged)) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id x088cYTp3431687 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 8 Jan 2019 00:38:34 -0800 Date: Tue, 08 Jan 2019 00:38:27 -0800 User-Agent: K-9 Mail for Android In-Reply-To: <28158fd7-8569-e0c1-75d0-c423330e256d@cn.fujitsu.com> References: <20190107074056.12532-1-caoj.fnst@cn.fujitsu.com> <000CE7C8-33F3-404A-9E7D-F2CCB0BA110E@zytor.com> <28158fd7-8569-e0c1-75d0-c423330e256d@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Subject: Re: [PATCH] x86/boot: drop memset from copy.S To: Cao jin , x86@kernel.org, linux-kernel@vger.kernel.org CC: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de From: hpa@zytor.com Message-ID: <1DA6B342-5F32-4C73-9352-4DB9F176D53C@zytor.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On January 7, 2019 12:52:57 AM PST, Cao jin wrote: >Hi, > >On 1/7/19 3:59 PM, hpa@zytor.com wrote: >> On January 6, 2019 11:40:56 PM PST, Cao jin > wrote: >>> According to objdump output of setup, function memset is not used in >>> setup code. Currently, all usage of memset in setup come from macro >>> definition of string.h. >>> >>> Signed-off-by: Cao jin >>> --- >>> Compiled and booted under x86_64; compiled under i386. >>> >>> Questions: now there is 2 definition of memcpy, one lies in copy.S, >>> another lies in string.h which is mapped to gcc builtin function. Do >we >>> still need 2 definition? Could we move the content of copy.S to >>> boot/string.c? >>> >>> At first glance, the usage of string.{c.h} of setup is kind of >>> confusing, >>> they are also used in compressed/ and purgatory/ >>> >>> arch/x86/boot/copy.S | 15 --------------- >>> 1 file changed, 15 deletions(-) >>> >>> diff --git a/arch/x86/boot/copy.S b/arch/x86/boot/copy.S >>> index 15d9f74b0008..5157d08b0ff2 100644 >>> --- a/arch/x86/boot/copy.S >>> +++ b/arch/x86/boot/copy.S >>> @@ -33,21 +33,6 @@ GLOBAL(memcpy) >>> retl >>> ENDPROC(memcpy) >>> >>> -GLOBAL(memset) >>> - pushw %di >>> - movw %ax, %di >>> - movzbl %dl, %eax >>> - imull $0x01010101,%eax >>> - pushw %cx >>> - shrw $2, %cx >>> - rep; stosl >>> - popw %cx >>> - andw $3, %cx >>> - rep; stosb >>> - popw %di >>> - retl >>> -ENDPROC(memset) >>> - >>> GLOBAL(copy_from_fs) >>> pushw %ds >>> pushw %fs >> >> This is dependent on both gcc version and flags. >> > >Thanks for your info, but I still don't quite get your point. All files >who has memset reference in setup will also #include "string.h", so how >gcc version and flags will associate memset reference to the assembly >function by force? Hope to get a little more details when you are >convenient:) GCC will sometimes emit calls to certain functions including memcpy(). -- Sent from my Android device with K-9 Mail. Please excuse my brevity.