From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH 02/10] x86/mm: override stored file names for multiply built sources Date: Tue, 20 Oct 2015 14:21:34 +0100 Message-ID: <56263FDE.4080407@citrix.com> References: <5626340902000078000ACB1F@prv-mh.provo.novell.com> <562635FC02000078000ACB35@prv-mh.provo.novell.com> <5626372C.6040308@citrix.com> <562659FA02000078000ACD9E@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZoWrW-0006SF-18 for xen-devel@lists.xenproject.org; Tue, 20 Oct 2015 13:21:58 +0000 In-Reply-To: <562659FA02000078000ACD9E@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: George Dunlap , xen-devel , Keir Fraser , Tim Deegan List-Id: xen-devel@lists.xenproject.org On 20/10/15 14:12, Jan Beulich wrote: >>>> On 20.10.15 at 14:44, wrote: >> On 20/10/15 11:39, Jan Beulich wrote: >>> To make it possible to tell apart the static symbols therein, use their >>> object file names instead of their source ones. >>> >>> Signed-off-by: Jan Beulich >> In principle, a very good idea. >> >> Is it perhaps worth having the build runes pass in a -D value instead, >> so as to avoid the .file reference getting stale? > They're not required to be in sync. Of course they are not required, but it will be incredibly confusing to debug if they are out of sync. > >>> --- a/xen/arch/x86/mm/guest_walk.c >>> +++ b/xen/arch/x86/mm/guest_walk.c >>> @@ -29,6 +29,8 @@ >>> #include >>> #include >>> >>> +/* Allow uniquely identifying static symbols in the 3 generated objects. */ >>> +asm(".file \"guest_walk_" __stringify(GUEST_PAGING_LEVELS) ".o\""); >> You should probably have a semicolon or newline at the end, to avoid >> interacting with whatever the next directive the compiler chooses to >> emit is. > We don't do this elsewhere (and the compiler takes care of this > anyway), so why should we care to do so here? Does it? If so, thats fine. ~Andrew