Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932225Ab2E3DKk (ORCPT ); Tue, 29 May 2012 23:10:40 -0400 Received: from terminus.zytor.com ([198.137.202.10]:60815 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932176Ab2E3DKj (ORCPT ); Tue, 29 May 2012 23:10:39 -0400 Message-ID: <4FC58EFE.2070705@zytor.com> Date: Tue, 29 May 2012 20:07:42 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Linus Torvalds CC: "H. Peter Anvin" , Borislav Petkov , "H.J. Lu" , Ingo Molnar , Ingo Molnar , Jarkko Sakkinen , Jeremy Fitzhardinge , Konrad Rzeszutek Wilk , Len Brown , Len Brown , Linux Kernel Mailing List , Matthew Garrett , Michal Marek , Paolo Bonzini , "Rafael J. Wysocki" , Sam Ravnborg , Thomas Gleixner Subject: Re: [GIT PULL] x86 trampoline rework for 3.5 References: <201205292325.q4TNPBPw007366@terminus.zytor.com> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2055 Lines: 60 On 05/29/2012 07:37 PM, Linus Torvalds wrote: > > but in your branch that "^pa_" pattern is duplicated for S_REL: > > /* > * These symbols are known to be relative, even if the linker marks them > * as absolute (typically defined outside any section in the linker script.) > */ > [S_REL] = > "^pa_", > > /* > * These are 16-bit segment symbols when compiling 16-bit code. > */ > [S_SEG] = > "^real_mode_seg$", > > /* > * These are offsets belonging to segments, as opposed to linear addresses, > * when compiling 16-bit code. > */ > [S_LIN] = > "^pa_", > > which looks odd. > > But that case with three patterns is the one you selected in your > merge - *not* the current state of relocs.c that you claim should be > selected. > Sorry, you're right. The version with three patterns is correct. The "^pa_" patterns are linear addresses which should be treated as relative, and so belong both to S_REL and S_LIN. This didn't surface as a conflict, so I forgot to flag it. > So I'm not pulling or merging anything until I understand what's going > on. Should I take the two-pattern one (which is what I have now, and > that seems sensible), or should that "^pa_" pattern really be merged > for two different cases (doesn't that just mean that the last one will > effectively override the first one)? > > Also, your branch adds an "x86-relocs" thing to the scripts/.gitignore > file that you seem to have removed in the merge. What was going on > there? That line should have been removed in checkin f2604c14 but wasn't; since that was one of the checkins that got folded up into 6520fe55 I cleaned it up at that time. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/