From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F20B4C2BB85 for ; Thu, 16 Apr 2020 14:22:25 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CF25D2076D for ; Thu, 16 Apr 2020 14:22:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CF25D2076D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jP5PC-0007EJ-4k; Thu, 16 Apr 2020 14:22:14 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jP5PB-0007EE-EP for xen-devel@lists.xenproject.org; Thu, 16 Apr 2020 14:22:13 +0000 X-Inumbo-ID: a9e2b7bc-7fed-11ea-9e09-bc764e2007e4 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id a9e2b7bc-7fed-11ea-9e09-bc764e2007e4; Thu, 16 Apr 2020 14:22:12 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id E5750AC37; Thu, 16 Apr 2020 14:22:10 +0000 (UTC) Subject: Re: [XEN PATCH v4 14/18] xen,symbols: rework file symbols selection To: Anthony PERARD References: <20200331103102.1105674-1-anthony.perard@citrix.com> <20200331103102.1105674-15-anthony.perard@citrix.com> <20200416124400.GG4088@perard.uk.xensource.com> From: Jan Beulich Message-ID: <312e719f-2bae-cb29-a6dd-29ae0d976d95@suse.com> Date: Thu, 16 Apr 2020 16:22:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200416124400.GG4088@perard.uk.xensource.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 16.04.2020 14:44, Anthony PERARD wrote: > On Wed, Apr 08, 2020 at 02:54:35PM +0200, Jan Beulich wrote: >> On 31.03.2020 12:30, Anthony PERARD wrote: >>> We want to use the same rune to build mm/*/guest_*.o as the one use to >>> build every other *.o object. The consequence it that file symbols that >>> the program ./symbols prefer changes with CONFIG_ENFORCE_UNIQUE_SYMBOLS=y. >>> >>> (1) Currently we have those two file symbols: >>> guest_walk.c >>> guest_walk_2.o >>> (2) with CONFIG_ENFORCE_UNIQUE_SYMBOLS used on guest_walk.c, we will have: >>> arch/x86/mm/guest_walk.c >>> guest_walk_2.o >>> >>> The order in which those symbols are present may be different. >>> >>> Currently, in case (1) ./symbols chooses the *.o symbol (object file >>> name). But in case (2), may choose the *.c symbol (source file name with >>> path component) if it is first >>> >>> We want to have ./symbols choose the object file name symbol in both >>> cases. >> >> I guess the reason for wanting this is somehow connected to the >> statement at the beginning of the description, but I can't seem >> to be able to make the connection. > > I'm not sure I can explain it better. > > The "object file name" file symbol is used to distinguish between symbols > from all mm/*/guest_* objects. The other file symbol present in those > object is a "source file name without any path component symbol". > > But building those objects with the same rune as any other objects, and > having CONFIG_ENFORCE_UNIQUE_SYMBOLS=y, changes the file symbols present > in the resulting object. We still have the "object file name" symbol, > but now we also have "source file name with path components" symbol. > Unfortunately, all mm/*/guest_*.o in one directory are built from the > same source file, and thus have the same "source file name" symbol, but > have different "object file name" symbol. We still want to be able to > distinguish between guest_*.o in one dir, and the only way for that is > to use the "object file name" symbol. So where's the difference from how things work right now? The "same rune" aspect doesn't really change - right now we also build with effectively the same logic, just that -DGUEST_PAGING_LEVELS=... gets added. I guess it might help if you showed (for one particular example) how the set of file symbols changes from what we have now (with and without CONFIG_ENFORCE_UNIQUE_SYMBOLS=y) to what there would be with your changes to the symbols utility to what there will be with those changes. >>> So this patch changes that ./symbols prefer the "object file >>> name" symbol over the "source file name with path component" symbols. >>> >>> The new intended order of preference is: >>> - first object file name symbol >>> - first source file name with path components symbol >>> - last source file name without any path component symbol >> >> Isn't this going to lead to ambiguities again when >> CONFIG_ENFORCE_UNIQUE_SYMBOLS? Several object files (in different >> dirs) are named the same, after all. Static symbols with the same >> name in such objects would hence resolve to the same kallsyms >> name. > > "object file name" symbol are only present in mm/*/guest_*.o objects, > they all have different basenames. There is no ambiguity here. At least not right now, I see. Could you make this aspect more explicit by adding something like "(present only in object files produced from multiply compiled sources)" to the first bullet point? Jan